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EDITOR'S NOTES 

It is my hope that this issue of "THE HEAP" will reach you 
prior to the New Orleans Symposium, but I expect that it probably 
will not. If not, please accept my apologies, the delay was en¬ 
tirely my fault, due to other, work related, pressures. 

This issue has three major contributions, all of which are 
of great interest. First is an article on TeX, the increasingly 
popular text formatting tool . for those of you who are not fami- 
lar with TeX, this will serve as a great introduction. TeX it¬ 
self is public domain software, and runs on a wide variety of 
machines, including most DEC CPU’s. It has an active and en¬ 
thusiastic user’s group, and after the article there is the in¬ 
formation and forms necessary to contact that user's group. 

The second submission is by Don Rosenthal, and consists of 
the slides from his Artificial Intelligence presentation from 
Anaheim, along with a very extensive A.I. bibliography. If 
you're interested in A.I., the bibliography alone is probably 
worth the cost of your subscription to "THE HEAP". 

The final major contribution is of extreme importance to 
FORTRAN users. You may be aware that there is currently work 
underway to design a new Fortran standard. This submission is 
the Fortran Information Bulletin which describes the features 
proposed for that new standard. When the publication of the FIB 
was proposed, both DEC and IBM voted against publication. Fol¬ 
lowing the FIB I have included DEC and IBM’s explanations for 
their negaitive votes, and following that is X3J3's response to 
DEC and IBM. I am endebted to Jay Wiley, our standards coordina¬ 
tor, for getting this information to me. I had to transcribe the 
responses, so I will apologize in advance for any typos or ommis- 
sions . 

One final submission may be of interest. You may or may not 
be aware that DECUS is considering combining the SIG newsletters 
into a single publication. This is an issue I feel strongly 
about, and I believe it will significantly impact how we are able 
to relate to you, the general membership. While I don’t really 
believe in editorializing, I feel this is important enough to 
make an exception. I have summarized my feelings, and what I be¬ 
lieve to be the current state of affairs. If you wish to com¬ 
ment, please do. My address, again, is: 

Alan L. Folsom, Jr. 

Dept 431, Fischer & Porter Co. 

County Line Road 

Warminster, Pa. 18974 

Finally, if you have not yet responded to the Wishlist from 
the last issue, please do so. I will continue to collate 
responses as long as I can, and will eventually forward the final 
tally to both DEC and the SIG leadership. 
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6et Ready for New Orleonel! 

- Kathy Hornbach, L&T Choir 

The New Orleans DECUS Symposium is just oround the comer, and it is one 
you certainly will not wont to miss. Besides the delicious Creole cuisine 
oround the comer from the convention center, the Symposium committee 
has put together an excellent slate of sessions ~ close to, if not THE, 
most sessions ever scheduled for a DECUS Symposium. This article will 
fill you in on some of the things planned. 

The theme for the Languages & Tools SI6 this symposium is Software 

Documentation Tools .hardly a glamorous subject, yet a very 

important one. No one likes to do it, yet everyone wants it to be done. We 
hove lined up some indepth technical talks behind this theme, and a number 
of users have submitted papers covering their experiences. Some of the 
highlights include a paper by DEC, describing the software tools they used 
to produce the top quality VMS V4 documentation. There are two talks on 
TeX, the public domain typesetting package written by Donald Knuth of 
Stonford, end a talk on WEB, on automated programming documentation old 
that grew out of the work with TeX. We plan to hold a number of 
birds-of-o-feother sessions on experiences in documentation techniques, 
so bring your war stories and success stories. 

As usual, DEC has sponsored a full slate of sessions giving the latest 
details an C, Pascal, Fortran, PL/1, CHS, MNS, DEC/Test 
Manager, DEC/Shell, and the rest. This will be an excellent time to 
consolidate the experience gained over the lost few months on the new 
versions of these tools. We olso expect to heor more details on some of 
the new products that were announced at Fall DECUS, including the 
Languoge Sensitive Editor, the new TPU editor, the Performance 
Coverage Analyzer, and Ado. 

We have invited members of the Fortran 8x standards committee to 
give presentations on the current stotus of the proposed standard. This 
will be followed by o panel session where the audience will be able to ask 
questions of both the standards committee and DEC’S Fortran developers. 

The SI6 is sponsoring three sessions where you will have a chance to meet 
the members of the Steering Committee and DEC developers in the 
Languages and Tools orea. These include the roadmap, first thing Monday 
morning when we fill you in on any last minute changes; and the wrapup, 
late Friday, afternoon when we assess the happenings for the week and ask 
for input from the audience on how to do our job better. The third session, 
and one you will definitely want to see, is the Wfshllst, DEC Feedback, 
and Questlen & Answer session Friday afternoon. DEC will respond to 
the top ten vote getters In the recent Wishlist distributed through the 
newsletter; then they will open the floor to feedbock on their current 




tools and suggestions for what they should worlc on next. 


You moy still hove time to sign up for one of the four PreSymposium 
seminars being offered by Languages and Tools. The only difficulty is in 
deciding which one to go to. (I'm teaching one, and I'm STILL having a hard 
time deciding!)! The seminars being offered include: 

Soft wore Project Development Using CMS/MMS — everyone has 
heard what CMS and MMS con do, but how does a project REALLY use them 
to control software throughout the lifecycle? How do you convince 
management that you need these tools? Bob Gable, who recently 
completed a stint using CMS/MMS to control source code on a project with 
over 50 developers and hundreds of thousands of lines of source code, will 
fill you in on the do's and don'ts of effective source code control. 

Developing Medium Scele Ado Applications Using VAX Ado — how 
do you take maximum advantage of the features of the Ada language — 
things like the Ada Compilation system, the debugger interface, etc? What 
is the best way to structure Ado pockoges to moke full use of the power of 
Ada? How does DEC Ado fit in with the rest of the VAX Common Language 
Environment? Bevin Brett, the instructor for this class, should be the one 
to know. One of the developers of DEC’S Ado compiler, he will put Ado into 
the systems perspective and show how it and the VMS environment con be 
used to develop software more effectively. 

Implementing e Software Development Environment —To increase 
productivity on during software development, automated tools are 
becoming more ond more prevelont. Tools ore now available to support the 
upfront requirements and design phases, as well os coding. This seminar 
exomines automated tools for software production, from on overall 
integrated viewpoint. It is not intended to teach how to use details of 
specific tools; rather it Is a guide to what is possible to do with software 
tools, what tools are available on the marketplace, how to convince 
management to buy the tools and how to convince programmers to use 
them. Tools covered support requirements, design, code, test and 
documentation. This will by taught by Kathy Hombach (yours truly) ond 
draws many examples from actual cose histories. 

Artificial Intelligence — A.I. is a subject that seems to be os much 
ot home in Business Week os in some of the more traditional computer 
journals. This seminar will present on overview of what A.I is oil about, 
for people alreody fomlltor with computers. It will talk about how A.I 
programs ore implemented and what is ond Is not possible with todoy's 
technology. The instructor, Greg Parkinson, is an Al developer for 
Cognitive Sciences, and works on natural longuage systems. 
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TfcX: TYPESETTING FOR ALMOST EVERYBODY 


Samuel B. Whidden 
Director, Computer Services 
American Mathematical Society 
Providence, Rhode Island 


Abstract 

This is an introduction to a typesetting program in the public 
domain. TfeX, and METAFONT, a companion program for font 
creation, were developed at Stanford by Donald Knuth. Together they 
form the basis of a powerful, customizable system for the typesetting 
of any text, especially text with complex mathematical formulations. 
TfeX (pronounced “techh”) runs on the 10, the 20, and the VAX. TfeX’s 
output files are independent of any typesetting device; output driver 
programs have been written for several typesetting machines. A macro 
facility allows TfcX to be tailored for fairly easy use by non-specialists; 
several customized macro packages have been written. “Style files” of 
macro expansions can be included at run time, permitting a macro 
call to have different expansions at, for example, preprint time and 
publication time, a feature that may permit TfeX to serve as a generic 
typesetting language as it becomes more and more widely used. 


I. The origins of TfcX and METAFONT 


1 

The Name of 
the Game 



FOIL 1 — Title page of Chapter One of The TgXbook 
by Donald Knuth, showing the TfeX logo. Illustration 
by Duane Bibby.* 


TfeX is a computer typesetting language created by Donald 
Knuth of Stanford University. This talk will be a survey 
of the current status of T£X and its companion program, 
METAFONT. I’ll tell you something of the reasons for 
their existence, something of what these programs can do, 
and a little of how they do it. I’ll give you a beginning 
understanding of how to use TfeX and I’D teU you how to 
obtain it, install it, get all the additional details you need, 
and how to get help with it from other users. 

The Greek letters T&u EpsUon Chi, pronounced 
‘techhh’, form, to quote Michael Spivak in The Joy of 
I)gX, “the beginning of the Greek word that means art, a 
word that is also the root of English terms like technology. 
This name emphasizes two basic features of TfeX: it is a 
computer system for typesetting technical text... and it is a 
system for producing beautiful text.” 

This foU reproduces the title page of Chapter One of 
The IfeXbook, by Donald Knuth. The Tj^Kbook is the 
principal document describing TfeX. It’s a book you’U need 
if you intend to use TfeX. I’D tell you how to get it at the 
end of my talk. 

The T^jX logo you see in this foD is normaUy typeset 
this way, with the lowered “E”, by TfcjX itself. It’s a small 
display of the power of TfeX. Trademark restrictions on the 
name “TEX” (rhymes with hex) make it necessary to spell 
TfcjX with a variety of lower and upper case letters—TtX— 
when the logo itself can’t be used. Later in my talk I’ll show 
you the commands that TfcX uses to generate this logo. 


* Reproductions from The TfiKbook, © 1984, American 
Mathematical Society; co-published by the American Math¬ 
ematical Society, Providence, RI, and Addison-Wesley Pub¬ 
lishing Company, Reading, MA; reprinted with permission. 
The T^X logo is a trademark of the AMS. 
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FOIL 3 — METAFONT. 
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TfcjX is designed as an output-device-independent system for 
composition. Each device that is actually used to produce 
TJgjX output must have character fonts to use for typesetting. 
“METAFONT is a system for the design of alphabets 
suited to raster-based devices that print or display text.” 
(Donald Knuth in the METAFONTbook) 

Knuth placed TfeX and METAFONT in the public 
domain and anyone may use them without payment to him 
or to Stanford. But he was concerned that TfcjX not be 
fragmented by various users into many incompatible versions 
and that a TfeX standard of typesetting be maintained. As 
a result, the TfcjX logo is a trademark of the American 
Mathematical Society, controlled so as to assure that 
systems called do what TfeX claims to do. 

Why is TfeX a typesetting system for ‘almost every¬ 
body’? TfcjX is a powerful typesetting tool. Because of its 
power, in applications beyond simple text it requires skill to 
use. It’s very much like a programming language, and can 
get complicated. In most installations, a TfeX wizard takes 
on the job of designing ways to handle complex material. 
Also, TfeX’s power is focused on scientific typesetting. It 
has language elements to handle tables and mathematics 
directly, but has no facility for graphics or for allowing 
text to flow around displays. So it is not the system 
of choice for newspapers, for example, or for CAD/CAM 
applications. But TfeX is ideal for the individual writer 
wishing to compose his document to best advantage. 


Cl. [Compute q , r tables.] Set stacks l\ V, C, and W empty. Set 

* «— 1 , 90 <— ^— 16, r 0 «— ri <— 4, Q 4, R *— 2. 

Now if g k _ l 4 ■ qt < n, set 

fc-fc+ 1 , Q-Q+R, R- Lv^J, qt-29, 

and repeat this operation until qt-i 4- qt > n. (Note: The calculation 
of R «— Lv^J does not require a square root to be taken, since we may 

simply set 7? «— # 4 - 1 if (J? 4 - l ) 2 < Q and leave R unchanged if 

{R 4- l ) 2 > Q) see exercise 2 . In this step we build the sequence 

*=01234 5 6 

fl* = 2 4 2 4 2* 2 8 2 10 2 13 2 16 ... 

r* = 2 2 2 2 2 2 2 2 2 s 2 3 2 4 ... 

The multiplication of 70000-bit numbers would cause this step to terminate 
with fc = 6 , since 70000 < 2 13 + 2 16 .) 

FOIL 8 — An example of pre-TfeX mathematical 
typesetting, from Vol. 2 of Knuth’s series of books on 
The Art of Computer Programming. 1 

In 1977, Knuth was faced with creating a revised edition of 
Volume 2 of his widely-read series, The Art of Computer 
Programming. The original edition, represented in this 
foil, was typeset by Monotype, a method involving skilled 
typositors using machines that produced metal type. The 
result was considered beautiful. 


(i) 


( 2 ) 


(iii) Wj(J,q,f 0 ) where 1<J<5 and f Q is a complex nuir 
Im f Q > 0 and Re < 1 . Further , neither q nor f Q - q 
S = ( f 0 + n: n an Integer ]. Wj(u,q .f p )/0 3 takes the form (j) j 
(b). 


For each of these representations v there is a basis for V 
if* 1 , t € S such that 


J 3 fL f) - mf<'> 


The algebra P is nearly simple if and only if the following bold: 

(a) N is spanned by «,•••, *, b v . • • , b k where ab = b 7 - 

«. 

(b) Either n — * = char F with k even or n — * * m char F for t 

Proof. By Theorem 5.5, there are elements a. b j, - * •, b k with N 
a, ••• b. *.. Furthermore, ab = 0, b? * a/i n ~ k ~ * b b « 

1 * iii i / 

for all », ; where each \ . f is in F. From this, it is clear that A! 
space of the space spanned by 1 , b Jt - ■ ■, b 

Assume P is nearly simple. Then there is a <f> with P{<f>) simple 
show that each b t is in M. To do this, it is necessary and sufficient 


:itJy mention all other topologies. We will also use the symbol Hk(£>) 
nil of the kernel of Q, i.e. 

2) = {j E m A : x(s) - 0 for every x € A for which x(Q) = 0). 

! norm topology for m A is equivalent to the one induced by the 
lyperbolic” metric: 

p(z, w) = Sup (lx(z)|: xEA, lx I < 1 and x(w) = 0}. 

will use D to represent the open unit disk in the complex plane, C, 
for the open unit polydisk in n-dimensianal complex space C". T* 
to the essential boundary of D n , i.e. 


FOIL 4 — Some examples of typesetting that Knuth 
considered unpleasing: Typewriter, Varityper, and 
Selectric Composer output. 

To a mathematician, the appearance of mathematics on 
the page is very important, but economics were forcing 
publishers to turn to composition methods which could be 
undertaken by less skilled, and therefore less expensive, 
personnel—for example, the Varityper and Selectric Com¬ 
poser methods. These examples are taken from Knuth’s 
paper, “Mathematical Typography”, which he presented as 
the Gibbs Lecture at the annual meeting of the American 
Mathematical Society in 1978, and which can be found 
in Knuth’s book “2feX and METAFONT, New Direc- 
tioD8 in Typesetting ”, published jointly by the American 
Mathematical Society and Digital Press. 

In this foil, example (1) is typewritten, example (2) is 
Varityper machine copy, and example (8) was prepared on 
an IBM Selectric Composer. 


[ACP], Vol. 2, p. 263. 


l 


2 


(1) Memoirs Amer. Math. Soc. No. 50 (1964), p. 82. 

(2) Trans. Amer. Math. Soc . 189 (1972), p. 282. 

(8) Trans. Amer. Math. Soc. 199 (1974), p. 870. 



Some computer systems existed (TROFF is one ex- II. 
ample) which either produced results which Knuth felt 
were less than satisfactory or which employed abstruse or 
highly-coded input. As a computer scientist, he felt he 
ought to be able to employ the computer in the service of 
mathematical typography. 


FIGURE ll. The letter S as defined by (a) Pacioli 
142]; (b) Torniello (48]; (c) Palatino (43]; (d) 

French commission under Jaugeon (24]. 

FOIL 5 — Examples of geometric constructs. 3 

Designers have attempted for centuries to use mathematical 
techniques to design letters, but with results which made up 
in rigidity what they lacked in art. 

sssssss 

FIGURE 12. Different S’s obtained by varying 
the slope in the middle. (This shows i, §, 1, j, 

and 2 times the “correct” slope.) 

FOIL « — A METAFONT-produced family of “S”es. 4 

As Knuth says, this letter S is brought to you by a program. 
Knuth found that, besides using typesetting in the service 
of mathematics, he could use mathematics in the service of 
typesetting. Cubic spline curves (equations containing some 
third-order terms) yielded pleasing characters whose forms 
could be manipulated by modern-day computers powerful 
enough to perform the necessary calculations. He designed 
the METAFONT program to allow alterations in the 
parameters describing a letter so it could be varied until it 
met an acceptable standard of style, and so that needed 
font family variations—upright, bold, slanted—could be 
generated with relative ease. 


3 [T&M], Mathematical Typography, p. 30. 

4 Ibid., p. 31. 


The Role of the American Mathematical Society 

FOIL 7 — A manuscript, in marked-up and typeset 
versions. 

Richard Palais, an AMS trustee, was in the audience when 
Knuth gave his Gibbs lecture on mathematical typography. 
Palais was impressed enough with Knuth’s design of 
TfeX and METAFONT to investigate their possibilities 
for typesetting AMS books and journals. The costs of 
scientific publishing had risen alarmingly. Palais discovered 
that nearly half of the publishing costs of a scientific 
journal arise from the process of copy-editing and retyping 
authors' manuscripts, and proofreading and correcting the 
typeset output. If an author had access to at his 
university, he could compose his article himself as part of 
his authorship effort. Palais’ hope was that, if use of IfeX 
became sufficiently widespread in the scientific community, 
the AMS might begin receiving some of its manuscripts 
already correctly composed in IjspC, ready to be output 
to a typesetting device and published with little further 
investment. TfeX’s ‘device independence’ could make that 
possible. 

FOIL 8 — A page from Mathematical Reviews. 

As far as I’m aware, the first large-scale continuous 
production use of TgX anywhere is the typesetting of 
Mathematical Reviews, the standard reviewing journal in 
mathematics, and its companion alerting journal, Current 
Mathematical Publications, both produced by the AMS in 
Ann Arbor, Michigan. These journals publish review text 
and bibliographic data on 3000 to 4000 mathematical papers 
per month, covering the world’s mathematical literature. 
Proof copy is set on a low-resolution laser printer, and 
final copy on a very high resolution Alphatype CRS 
phototypesetter. Since identical fonts are used in both 
cases, the output of both machines is formatted identically, 
making it possible to perform all proofreading and correcting 
operations on the inexpensive device. 

Other organizations, including Digital, are also be¬ 
ginning to use IfeX, so far mostly for one-time, though 
sometimes large, documentation jobs. 

FOIL 9 — The Combined Membership list, the 
AMS Catalog of Publications, and the Mathematical 
Sciences Professional Directory are examples of TfeXed 
AMS publications. 

TfeX is still new, and the AMS does not yet typeset the bulk 
of its primary journals in TfeX. That may come about over 
the next couple of years. As experience has been gained in 
the use of Tj^X, production costs have dropped at least to 
the level of previous typesetting systems used by the AMS. 
Some AMS books and journal papers are already being 
TfcjXed, as are nearly all of the Society’s administrative 
publications, most of which are too complicated to be set 
easily by other methods. 

This foil displays samples from three of the Society’s 
administrative publications—its catalogue and two of its 
directories—which are set completely by TgX, without 
separate page make-up or cut-and-paste. Results so far 
seem to show that the more complex the typesetting 
requirements, the more cost-effective is TgX. And Tfejt is 
becoming available on a growing range of hardware, making 
it a contender to become a universal composition language. 
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FOIL 7 — A manuscript, in marked-up and typeset 
versions. 
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CALCULUS OF VARIATIONS AND OPTIMAL CONTROL; OPTIMIZATION 


162 


Lagrange equation and the Newton-Raphson method need be cal¬ 
culated by hand. An example it fiven with numerical results. 
The automatic solution of the simplest problem in the calculus of 
variations in this paper is considered to be the first step in the 
automatic solution of more general optimal-control problems.” 

49A Existence theory for optimal eolations 

See also 48017, 47052, 40006, 58011, 60066, 

72070, 76067, 00246, 02006, 02070, 02003. 

Marcelllnl, Paolo (I-NAPL-E); 85*40008 

Sbordons, Carlo (I-NAPL) 

On the existence of minima of multiple Integrals of the 
calculus of variations. 

J. Moth. Peres AppL (0) 62 (1082), no. 1,1-0. 

Let f) be a bounded open set in R* and /(z, s, f) a Carat hlodory 
function on fl x R* x K mff such that |{|* < /(*, s, f) < a x (x) + 
et|#|* + with «i € I£ c (fl), a > 1, p > 1, a»,a* > 0. The 
function / is assumed to be quaskonvex in the sense of C. B. 
Morrey, Jr. (Pacific J. Math. 2 (1052), 25-52; MR 14, 002]. The 
authors consider the variational problem 

(P) toljjf+ 

where Mo is a fixed function of (H l *[Q)) N . They prove the fol¬ 
lowing theorem: There exist a number q > p and a sequence min¬ 
imizing the problem (P) that is relatively compact in the weak 
topology of (tf£*(fl)) . Because the integral under consideration 
b lower semicontinuous in the weak topology of (Jf£*(n)) N for 
every q > p, the authors obtain as a corollary that the problem 
(P) has a minimum. Their proof makes use of, among other things, 
a variational principle of I. Ekeland (BulL Amer. Math. Soc. (N.S.) 
1 (1070), no. 3, 442-474; MR 8Oh:40OO7] and an argument con¬ 
cerning regularity in (#£,’*(0))* (for any f > p) in the sense of 
N. G. Meyers (Ann. Scuola Norm. Sup. Pisa 17 (1063), 180-206; 
MR 28 #2228] that was introduced in the context of minimum 
problems by M. Giaquinta and E. Giusti (Acta Math. 148 (1082), 
31-46; MR 84b:58034|. Venae Zendli (Modena) 

Barbu, Viorel (R-IASI) 85a:40000 

Optimal feedback controle for semlllnear parabolic 
oquatlone. 

Metkemeiicel theories of optimisation (Geneva, 1081), 42-70, 
lecture Notes in Moth., 070, Springer, Berlin-New York, 1083. 
The author considers the problem of exbtence of an optimal feed¬ 
back control for the system yi+Ay + ^(y) = Bu ((z, t) € flx(0, <)), 
y(z,0) * po(z) (z € fl), y(z, t) * 0 ((z, 1) € E = T x (0, t)) with the 
coat functional 

jf r (*M»))+*(«(»») *+•(»(*■)). 

Here fl b an open bounded subnet in n-dimensional Euclidean 
apace with sufficiently smooth boundary T and Aba uniformly 
elliptic eeUadjoint partial differential operator, 

a * ]£ 53 +«•(*)• 

The operator B b linear and bounded fro:r a real Hilbert space 
U to L*(n) and the functions #, 0,/5, and h satbfy various as¬ 
sumptions that we will not detail here. There are abo results on a 
control problem with infinite time horizon and on the time optimal 
control problem as a limit of a sequence of problems of the type 
described above. 

{For the entire collection see MR 84g:40OO3.} 

E. 0. Fnttorini (Los Angeles, Calif.) 

Canaa, Eduardo (E-ZRGZ) 85*40010 

Quelquee problfcmes de controls avee eontralntee sur 
l*4tat. (English summary) (Optimal control problems 
with constraints on the state] 

C. R AoU Sd Porte Sir. I Moth. 266 (1083), as. 12, 500-512. 


Author's summary: In thb note we consider a class of optimal 
control problems with constraints on the state. We associate a 
Lagrangian to the control problem and prove the exbtence of 
Lagrange multipliers in a space of measures. Finally, we study 
some properties of these multipliers.” 

Ekeland, I.; Lasry, J.-M. 85a:40011 

Duality In noneon vex variational problems. 

(French summary) 

Aiooneet in Bemdtonien systems ( Rome , 1081), 72-108, Ana. 
CEREMADE, Birkkineer, Boston, Moss., 1082. 

The authors develop a duality method for obtaining critical points 
of functionals which split into a quadratic term and a convex term. 
The main abstract theorem b the following: Let V be a reflexive 
Banach space, A : V —• V* linear, continuous and seUadjoint, and 
let F : V -* R u {+»} be convex lower semicontinuous, with 
dom F ft #. Let / and J be functionab on V defined by: 

/(u) = }(An, u) + F(t i), J(v) * { (Av, v) + F*(-Av), 

where F* : V* -* Ru (+oo) b the Fenchel conjugate of F. Then 
any critical point of J b also a critical point of J. Moreover, if 
0 € Int(domF" + R(A)) and vba critical point of J, then there 
b some 0 € KerA such that 6 + 0 in a critical point of I. 

In the ease where F(u) * G(#fu), with G : X -* Ru {+oo} 
convex and K : V -* X continuous linear, one can replace the 
hypothesb on domF* + R(A) by easier conditions; thb leads to 
the concept of a pseudocritical point. When K b compact and 
G b subquadratic at infinity or superquadratic at the origin, a 
study of the dual functional J reveals the exbtence of critical or 
pseudocritical points. In the second half of the paper the abstract 
results are used to prove the exbtence of periodic solutions of a 
nonlinear wave equation describing a vibrating string, and also 
to prove exbtence of solutions to the following boundary value 
problem for a damped Hamiltonian system: 

i = V,H(t,z,p), *(0) = z(T), 

p=-V,H(t,z,p)-ap, p(0) ■ exp(ar)p(T). 

{For the entire collection see MR 84j:5800l.) 

A. Vonierbonwkede (Ghent) 

Pal, D. V. (6-HT) 85a:40Ol2 

On nonlinear minimisation problems and L /-splines. I. 
J. Approx . Theory 30 (1083), no. 3, 228-225. 

Let X, Y be a pair of separated locally convex spaces, T:X -+Y 
a continuous operator, /:K-*Ru {+oo} * lower semicontinuous 
proper convex function, and C a closed nonempty subset of X. 
The following problem (P v ) b considered: Given an element y € Y, 
minimise / over T(C)-y. The author presents various conditions 
which ensure that the problem (P,) has a solution for each y € Y. 
In particular, he deduces the exbtence of so-called Lf- splines in 
C , Le. solutions of the problem (P 0 ) when Tba bounded linear 
operator. W. W. Breekner (Cluj-Napoca) 

Barlee, Guy 85*40013 

In4quatlons quasi varlatlonnelles du premier 
ordre et 4quatlons de Hamilton-Jacobi. 

(English summary) (Quasivariational Inequations of 
first order and Hamllton-Jacobl equations] 

C. R. AoU Sei. Peru Sir. I Moth. 206 (1082), no. 15, 703-705. 
Author’s summary: ‘We prove various exbtence and uniqueness 
results of solutions of first order quashmriational inequalities in 
R*. These results rely on the notion of a viscosity solution of the 
Hamilton-Jacobi equations, properly extended to thb context.” 

Hoffknan, K. H. (I-ROME); Nlesgodgka, M. 85*40014 

(I-ROME) 

Control of parabolic systems Involving free boundaries. 
Free keen dory problems: theory end eppkeetions, VoL I, 

U (Montseotini, 1081), 431-462, Ret. Notes in Motk, 78, 
Pitmen, Boston, Most.-London, 1083. 

The paper offers a very interesting survey on recent advances in 
the methods of solving various control problems by the study of 


FOIL 8 — A page from Mathematical Reviews. 
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Proceedings of the International 
Helainki 1978 

The Pmneeriings of the 
August 15-23, If 
Congrats, the 


sod applying for a position, 
art listed. The Mathematical 
by the American Mathematical 
and the Society ‘ 



This is a guide to computer 
T}$C r epresents state-of-the-art in 
where the article, document, or book 
notation where the user is concerned 
1g( software offers both writers and pul 
nical text with the sp eed and efficiency of a 
the American Mathematical Society and Ad< 
spiral bound (LC 83-830; ISBN 0-201 

The Joy of Tg£ 

The Joy of 1£X is the user’s guide for 
typesetting program T^jX. ‘IJspt 
technical material, while Ap$ 

Sprrak to alkm for 
of requires, 

This 1883 edit 
edition of the _ 

*TBXT8’), and a 
with the current 
of The Joy of T^X, 

Use of AmMEX 

8unnyvale, CA 94087, 

John yon Neumann, 

This is Bulletin, Volume 
John eon Neumann edited 
1881; 130 pp. (ISBN 0-8211 

Norbert Wiener, 1894-11 

This edition of Volume 72, 
dedi c ated to the memory of 
Kahane, S. Mandalbrojt, P. 

Wieener, M. Brelot, M. Kac, J. 
tioau. 1966, reprinted 1882, 145 pp. 

TOLL FREE BOOK 


NW 20.00 16.00 

L USERS OF VISA/MASTERCARD - 800-556-7774. 


FOIL 9 — The Combined Membership list, the 
AMS Catalog of Publications, and the Mathematical 
Sciences Professional Directory are examples of TfcXed 
AMS publications. 
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III. Structure of the TfcX end METAFONT System 

Knuth wrote T£X & METAFONT originally in SAIL, the 
Stanford Artificial Intelligence Laboratory's programming 
language. The programs have gone through several 
generalizations, and the current versions are written in 
'WEB', a documentation/programming language invented 
by Knuth to make TJ«*X and METAFONT universally 
distributable. Naturally, anything written in WEB must be 
processed by TANGLE and WEAVE. 


The WEB System 


WEB source 



source 

I 

Pascal 

compiler 

~T" 

Pascal 

program 



WEAVE 
~~ 

T& 

input 

1 

I T& I 


1 

Documentation 


* installation Change files 


FOIL 10 — The WEB system. 

From the same WEB source code, TANGLE generates 
Pascal source code and WEAVE generates a TfeX-input 
documentation file. Of course, many more programs than 
just Tfc*X and METAFONT have been written in WEB— 
including TANGLE and WEAVE. If you obtain TJgjX, you'll 
receive on the same tapes a copy of Knuth's paper entitled 
Literate Programming , which provides more information on 
the WEB system. Knuth asserts that the work of the author 
of a program should be as literate (as opposed to illiterate) 
as that of any other author. He sees literate programming as 
the successor to structured programming. Computer science 
may be seeing much more of WEB. 


Generic TJrjX distribution tape - Selected files 


-READ-. ME 

Overall documentation and 
instructions 

TANGLE.WEB 

TANGLE.PAS 

Use this file to bootstrap and test 
TANGLE 

TANGLE. CHARGES 

Changes used to create TANGLE.PAS 
from TANGLE.WEB 

WEAVE.WEB 
DVITYPE.WEB 
TEX.WEB 

Prints out DVI files 

TEX82.BUG 

Explains all changes made to TfeX 
since version 0 

PLAIN. TEX 

The basic macro package for Tfc*X 


HTPHEN.TEX Hyphenation patterns, used by 
PLAIN.TEX 


SAMPLE.TEI Small Tfejt job to show font layout 
TRIP. * Test suite for 1feX 

TRIPMAN. TEX TfeX source of the T&IP manual 
AM*. TPM Font metrics for Computer Modern 

fonts 

Macro packages and documenation: LATfcX, AxS-TfeX, 
HP-TfcX 

The TfeXbook 

System-specific files: TOPS-20, VAX/VMS, IBM 
VM/CMS, IBM MVS 

M7.WEB Preliminary version, new 

METAFONT 

PLAIN.MF Plain METAFONT macros 

SYNTAX. TEX What there is of a user manual 


FOIL 11 — Major files on the TfejX/METAFONT 
installation tapes 

You can obtain the TfeX and METAFONT programs from 
a tape distribution service bureau in Sunnyvale, California. 
An order form giving details is attached as Appendix A. 
This foil lists a few of the files on the tapes you'll receive. 
One file tells you what to do with all the other files. You 
start by compiling the Pascal source of a bootstrap version 
of TANGLE. (If you have an off-beat Pascal compiler, I'm 
told you may have to make changes in tangle.pas.) 

This compile gives you a preliminary version of 
tangle.exe. You use this to TANGLE a tangle.web source 
file from the tape, which gives you a new tangle.pas, which 
you compile into a new tangle.exe. Knuth intends that 
we not make any changes in the .WEB sources which 
these tapes supply. Therefore, in this step, along with 
the tangle.web source, TANGLE reads a tangle.change file 
(which you can change and of which there is a model on 
the tape), which specializes the resulting tangle.exe for your 
installation. 

Next, you feed the tex.web source on the tape to your 
new TANGLE and get a tex.pas, which you compile to get 
a tex.exe. Now you TfcjX the TRIP files on the tape and 
see whether the resulting output is the same as the TRIP 
output file on the tape. If so, you have a good IfeX. If not, 
the documentation tells you what to do. You generate the 
METAFONT program in a similar manner. 

Once you have a good TfcjX, you can TANGLE the 
weave.web on the tape, then WEAVE the tex.web file, 
generating a tex.tex file, which you then TfeX to generate 
TfeX's own program documentation. See how simple it is? 

Some utility programs (called TJsXware) also come on 
the tape. DVItype, which converts .DVI files into readable 
output, is one. 

There are a few versions of TfeX already specialized for 
particular hardware systems which can be ordered in place 
of the generic one. Such special versions exist for VAX/VMS 
and for TOPS-20, among others. 

Some manuals can be ordered along with the tapes, 
notably manuals for WEB, TRIP, and TfeXware. TfeX source 
for The TfiXbook itself is also on the tape, although it 
can't be reproduced, because not sill the necessary fonts 
are present (and it should not be reproduced because it is 
copyrighted). This source file is very useful, however, as a 
nearly endless source of examples for doing things in TfejX. 
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Generating TfeX by the procedure I’ve described 
creates a version of TfcX called INITEX. INITEX then 
allows loading of a hyphenation pattern file (see The 
TfiXbook, Appendix H), .TPM files, style, or header, files 
(which usually includes plain.tsx; XxS-TfeX and IATfeX 
are others. I’U return to these style files later), and any 
other files of macros desired. The resulting version of 
T)qX, with these additions preloaded, is saved for production 
use. Several different production versions, preloaded with 
different fonts and style files, can be generated if necessary. 

The / METAFONT System 



FOIL 12 — The TfeX/METAFONT system. 

Once you have a working version of TfeX (and of META¬ 
FONT, if you’re going to install that, too), you’re ready to 
use them. METAFONT reads character descriptions in its 
own input language, creating two kinds of output: TfcsjX Font 
Metrics (.TFM) files, and raster-image (.PXL) files. 

The font metrics files contain character dimensions and 
reference points, plus kerning, ligature, and possible piecing 
information (for very large characters). The .TFM file is 
the same for all raster sizes and is used directly by l&X to 
calculate the size and position of each character on the line. 

The .PXL file contains the actual bit maps of the 
characters in a given point size for a given output resolution 
(for example, 240 dots per inch or 500 dots per inch, which 
are common laser printer resolutions at present). (These 
files are very large; for some very high resolution output 
devices, another program might be used to compact the very 
large bit maps into a shorthand recognized by the machine.) 

TfejX reads the .TEX input file, along with whatever 
.TFM files are called for by the text, and produces a 
device-independent .DVI output file. The .DVI file is 


read by device-specific programs which translate it into 
commands recognized by a specific output device, merging 
raster patterns from the necessary .PXL files, and transfer 
the results to the device a line or a page at a time for 
outputting. Drivers exist for a number of both low- and 
high-resolution devices. 

Since the distribution tapes already contain .TFM and 
.PXL files for standard text fonts in several point sizes and 
resolutions, it is usually not necessary to install META¬ 
FONT unless you need to generate special fonts (in fact, 
for greater efficiency, the common .TFM files can actually 
be pre-loaded as tables in your production version of l^X 
by INITEX). Fonts can also be obtained from other TfcjX 
users. A bit more about METAFONT later. 


Proof-Qualty Output Devices Supported mm DEC Computers 


DEC 10 

DEC 20 

VAX (Unix) 

VAX (VMS) 

Facit 4542 




INFN/CNAF 

Florida Data OSP 


Math. Reviews 



hnafen 8/300 


Math. Reviews 



hnafen Imprint 10 

Stanford: 

Vanderbilt 

SRI: 

Columbia 

UC Irvine 

Kellerman 

A Smith 4 

QMS Lasergrafix 

Talaris 

Talaris 

Talaris 

Texas 

AIM 

Symbolics LGP-1 


U of Washington 

U of Washington 

Calma 

Varian 


AMS 


Science 

Applications 

Versa tec 

G A Technologies: 
Vanderbilt 

U of Washington 

U of Washington 

Kellerman 

A Smith 4 

Xerox Dover 


CMU 

Stanford 


Xerox 9700 

U of Delaware 





* Graphics supported 


FOIL IS — Proof-quality output devices for DEC 
computers. 

This and the next foil are examples of fairly simple tables 
set by TJeX. These are some of the low-resolution, proof 
quality output devices that have been interfaced to TfeX on 
Digital machines. I’ll tell you shortly how to obtain this 
information from the source. 


Typesetters Supported uu DEC Computers 


DEC 20 

VAX (Unix) 

VAX (VMS) 

Atphaty: CRS 

AMS 



AeMcgk APS 5. Mk.ro-5 

Textset 


Intergraph * 

Compugraphic 8400 



Kellerman 

A Smith * 

Harris 7500 



SARA 

(Amsterdam) 

Mergenthaler Lmotron 202 

Adapt. Inc. 




4 Graphics supported 


FOIL 14 — Repro-quality output devices for DEC 
computers. 

These are the camera-quality output devices that currently 
can provide TfeX output from Digital machines. 
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IV. Something of How TfcX Works 

11 

Boxes 



FOIL 16 — Boxes; Title page of Chapter Eleven of 
The TfiXbook. 

Knuth designed into TfeX the interesting concepts of “boxes” 
and “glue”. TJg»X puts each output token it encounters into 
a box. Each letter is a box. So are interword spaces, 
discretionary breaks, and so on. Several such boxes together 
form a larger box to make a line. Once a box is built, it is 
fixed; TfeiX manipulates it as a single token. 

12 

Glue 



FOIL 16 — Glue; Title page of Chapter Twelve of 
The T&Cbook. 


Boxes are held together by glue. Glue comes in standard, 
but variable, amounts. Glue can stretch an allowed amount, 
when it needs to, and can shrink as well. Both the 
stretch ability and the shrinkability have limits, which may 
be different and which you can specify. IfeX will complain 
when you ask it to stretch or shrink glue beyond the limits 
you’ve given it. These limits, as well as a great many 
other things, are specified to IfeX in terms of units and 
dimensions, such as inches or points or picas or ems, which 
T&L understands. 

One of a typesetting system’s chief duties is to take 
a long sequence of words and to break it up into 
individual lines of the appropriate size. 

One of a typesetting system’s chief duties is to take a 
long sequence of words and to break it up into 
individual lines of the appropriate size. 

One of a typesetting system’s chief duties is to take a 
long sequence of words and to break it up into individual 
lines of the appropriate size. 

One of a typesetting system’s chief duties is to take a 
long sequence of words and to break it up into individual | 
lines of the appropriate size. 

FOIL 17 — Baxes & Glue; Stretching & Shrinking. 

This foil shows a sentence set with four different specificar 
tions for glue setting. The first example is loosely set, with 
interword glue stretched, but not beyond its limits (there is 
no glue between letters). 

The second example shows neither stretching nor 
shrinking of the glue. 

In the third, the glue is shrunk nearly to its limit. 
Normally, glue can stretch a lot more than it can shrink. If 
the words in this example were much closer than this, the 
line would probably be unacceptable. 

In the last example, the glue is permitted so little 
flexibility that cannot fit the material into the space 
allowed. So it shrinks the glue as much as permitted, lets 
the line stick out beyond the right margin, and puts a black 
mark here to tell you where the trouble is. It also writes a 
nasty message to your screen when it does this. 

In Vol. 14, No. 4 (Oct. 29, 1984), The Seybold Report 
on Publishing Systems reviewed TfeX in connection with 
a lyC-based microcomputer typesetting system developed 
by Tyxset Corporation. One of the few complaints raised 
against TfeX by the reviewer is that TfeX puts out these 
overfull boxes, rather than simply moving the offending 
word down a line, with a suitable warning to the user. A 
very loosely set line, while unattractive, is much more likely 
to be printable than an overset one. But IJsX would rather 
have you change the wording a little or add a discretionary 
hyphen to make the output acceptable. After all, has 
its own reputation to maintain. 

T£X uses a hyphenation algorithm developed by Knuth 
and one of his associates, Frank Liang. TfcX has been taught 
to avoid hyphenation errors as much as possible by avoiding 
hyphenation as much as possible. Nevertheless, ijipC knows 
how to hyphenate most words and has a hyphenation 
dictionary which you can add to if necessary. You can tell 
lfeX how to hyphenate specific words as part of your input 
file, and you can insert discretionary hyphens anywhere you 
want. 
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How T^X Breaks 
Paragraphs into Lines 



FOIL 18 — Linebreaking; Title page of Chapter 14 of 

The TftXbook. 

TfeX breaks lines into paragraphs only after it has read 
the whole paragraph. Then it considers all possible break 
points, assigning penalties to breaks which give undesirable 
results, such as very loosely or tightly set lines, or multiple 
hyphenated lines in a row. TJgX selects the set of linebreaks 
which minimize the total “badness”—the sum of all such 
penalties—for the paragraph. Knuth has devised algorithms 
which reduce the number of tests required, making this 
process relatively fast and efficient. There are simple ways to 
override these automatic linebreaks by tying words together 
so no break occurs between them, or by forcing a break 
where one would not otherwise occur. 

V. Using IfcX 

A Simple Input Example 

The input 

This is an easy example of input. 

\bye 

yields 

This is an easy example of input. 

FOIL 19 — A simple sample of TJgjX input and output. 

Now we’ll look at a few examples of how T^pC is used. This 
foil shows the easiest possible T)e*X input. I typed this line 
and submitted the file to TfeX. Because the production l)gpC 
at my installation is preloaded with standard fonts and the 
plain.tax style file, the line came out neatly typeset in the 
default roman font of our laser printer. 


Control Sequences 

A control word is composed of a backslash and one or 
more letters. It must be terminated by a non-letter. 

\AE top JEsop (Latin and Scandinavian ligature jE) 

\P2 ^2 (paragraph sign) 

\eject (force page break) 

\ytar (get the year of today’s date) 

A control symbol is composed of a backslash and a 
single non-letter. 

\ft A (ampersand) 

\- (discretionary hyphen) 

\"o 6 (umlaut accent) 

FOIL 30 — Control sequences: Control words and 
control symbols. 

For the most part, TfejX’s input consists of a mixture of text 
and commands. Commands, which are always introduced by 
a backslash, are called “control sequences”, which are either 
control words or control symbols. A control word must be 
delimited by a non-letter; a control symbol is always just a 
single character following a backslash. 

Typical Symbols and Accents 

Most symbols must be keyed in “math mode”. 

\S A. 1 §A.l (section sign) 

$\alpha$ a (Greek letter alpha) 

$\gg$ > (much greater than) 

$\ln$ £ (membership symbol) 

Accents may be set above or below letters or symbols. 

Vo 6 (acute accent) 

\v i S (h&ek or “check”) 

\c c 5 (cedilla accent) 

$\vec\kapp&$ k (“vector”) 

FOIL 21 — Symbols and Accents. 

TJjjX knows about a wide selection of special symbols and 
diacritical marks in many fonts. You set them by means 
of control sequences like these. IfeX only knows about 
many of the symbols when it’s in “math mode”, since it 
considers such things as operators and greek letters to be 
mathematical symbols rather than characters in ordinary 
text fonts. You put “$” signs around the portion of your 
input you want TfeX to process in math mode. 

An Example Using Math Mode 

Suppose $s=0$. Thtn tH_s~+$ is the space of 
functions in $L_2({\bf R}~n)t that vanish 
for $x_n<0$. 

Suppose 8 = 0. Then Hf is the space of functions in 
L 2 (R") that vanish for z„ < 0. 

FOIL 22 — A simple example of math mode. 

In math mode, TJgX takes over the positioning of characters 
and the spacing between them. Mathematicians are fussy 
about style, and TfeX doesn’t leave such important matters 
to chance. Of course, you can override most of TfeX’s 
decisions if you wish. Ordinary math mode results in 
mathematical material set in line with non-mathematical 
text. 
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Primitives and Macros 

Primitives are control sequences that are built into TJgpC. 
\read (read in a file) 

\uppereass{abe} ABC (uppercase the string) 

$\undtrllnt{xyz}$ zyz (underline the string) 

Macros are control sequences that are abbreviations 

for longer strings of control sequences or text. 

\centerlins{...} (center string on a line) 

\nlnspoint (use 9-point fonts) 

FOIL 23 — Primitives and Macros. 

Some control sequences are “primitives”, built right into 
Tfc»X; others are “macros”, the result of definitions made by 
users. The file plain.ttx is a collection of macros defined 
by Knuth himself to make it easier to get TJjjX to do common 
and useful things, plain.ttx is normally preloaded into a 
production TfeX by INI TEX. 

Defining and Using Macros 

\dtf\llnt{\hbox to\hsi*t> 

\dsf\csntsrlins#l{\lins{\hssti\hss» 

\ctntsrlinr{In the Middle} 

yields 

In the Middle 

FOIL 24 — Defining and using macros. 

Here we see some examples of macro definitions. Macro 
definitions always consist of the control sequence \def 
followed by a control sequence which will become the name 
of the macro, followed by the string, enclosed in grouping 
symbols, which the macro name will stand for. 

First we \def the macro \line, which consists only 
of a horizontal box (\hbox) the width of our page 
\hsize. If we were to use the macro \line directly by 
typing \line {followed by some words inside grouping 
symbols}, TfeX would set those words in a line of width 
hsize, stretching or shrinking the interword glue to make the 
best fit it could. 

But now we \def the macro \centerline which we’ll 
use to put something into the horizontal box called \line. 
The string defined by \centerline consists of the macro 
\line with the expansion {\hss#l\hss}. The #1 in the 
name of the macro stands for an argument, and the same 
symbol in the macro definition shows where the argument 
goes when the macro is expanded. \hss is a IfeX primitive 
standing for essentially infinitely stretchable horizontal glue. 
When \centerline is called with an argument like “In The 
Middle”, the argument is set between two pieces of glue with 
great stretch ability, so the result is centered on the line. 
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FOIL 25 — First Grade IfeX; Title page output 

Anyone who is serious about using TfeX will begin by 
studying a short manual called First Grade TfiX. by Stanford 
Professor Arthur Samuel. 

This is the cover page of First Grade 2JgX. The next 
three foils will show the input that created this page. Note 
the material at the top of the page, the title and author’s 
name in the middle, the Stanford Seal in the bottom half of 
the page, and the final paragraph of text. 

\font\nlnaniFanr9 \font\tightr«=ainr8 

\font\tixrai=ainrC \font\csc=aiuctclO 

\font\stal s stan70 X To product tht Stanford ttal 

\dtf\TtX{T\ktrn-.1607 taX 

\lovtr. 6tx\hbox{E}\ktrn-. 126ta X} 

\aagnification=1200 X This aagnlflts tvtrythlng by 1.2 
\pariklp lOpt pint lpt 

X Tbit putt tomt tapty tpact bttvttn paragraphs 
\parlndtnt Opt X Paragraphs art not to bt indsntsd 

\nopagtnuabtrs X Tht tltls pagt It not to bt nuabtrtd 
\null\vsklp-46pt X Put first lint higher than noraal 

FOIL 26 — First Grade TfeX; Title page input - 1 

The first part of the input names some .TFM files that TfeX 
will need in later input that were not preloaded, including 
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a file named Btan70.tfm, which will be needed when & font 
named “SEAL” is called for. The a %” denotes a comment; 

ignores everything on the line after it. 

Next the TfeX logo is defined as a macro called \TeX. 
The first token in the definition string is an uppercase 
T. Next is a negative kern, which is a mechanism for 
backspacing so as to bring two characters closer together 
than the .TFM metrics would place them. The kern is in 
units of “em”s, where an em represents the width of an M 
in the current font. Next, an uppercase E is put into a 
horizontal box and lowered slightly, then an X is set and 
kerned back. Everywhere you see the TJejX logo in these 
foils, this macro produced it. 

“Magnification 1200” means use fonts of the 10-point 
design which have been enlarged to 12 points (actual 12- 
point fonts would have a slightly different shape). The 
proper .PXL raster files must be available to the output 
driver for this to work. 

\parskip and \parindent are TfeX primitives whose 
default values are being reset here. There will be 10 points 
of vertical glue between paragraphs, with 1 point's worth 
of stretchability and no shrinkability. There will be no 
indentation at the beginnings of paragraphs (note that the 
amount has to be specified even where it is zero). This page 
won’t be numbered (the default would center a number at 
the bottom of the page), and the page will be set higher 
than normal on the paper (glue at the beginning of a box, 
such as a page or a line, disappears, so a null box is set 
before the \vskip on the page). 

\hboxto O.fitrneln {November 1083 \hfil 
Report No. STAN-CS-83-986} 

X A convtnient way to make a box of apaclf 1c size. 
\vskip . lln X Skip down 0.1 inch 
Mine {Stanford Department of Computer Science\hfil 
(Version 1)> 

\vfill X This and similar commands later, 

X will divide the space evenly. 

\centerllne{\bf First Grade \TeX} 

\centerllne{\bf A Beginner’s \TeX\ Manual! 

\vsklp .251n 
\centerllne{by> 

\centerllne{Arthur L. Samuel} 

Wfill 

\centerllne{\seal S} 

\vfill 


FOIL 27 — First Gr&de JjgX; Title page input - 2 

Next we enclose material in a couple of boxes with 
horizontal spacing to cause material to be right and left 
justified. Several \vflll vertical spacing commands will 
divide up the unfilled space on the page. Some lines 
are centered horizontally, and then the character tf S” in 
the “SEAL” font—that is, the character which occupies 
the normal “ASCII grid” position of the letter U S” in 
in the Stan70.tfm font file (produced by somebody using 
METAFONT), is set. That produces the Stanford seal in 
the center of the page. 


This manual Is bassd on ths publications of 
Donald E. Knuth who origlnatad ths \ToX\ system and 
on ths rscsnt work of Prof tssor Knuth and his many 
studsnts and collaborators who havo helped bring the 
\TeX82 system to its present advanced state of 
development. The \TeX\ logo that is used in this 
manual is a trademark of The American Mathematical 
Society. The preparation of this report was supported 
In part by National Science Foundation grant 
IST-820/926 and by the System Development Foundation. 
\eject X Vend would follow If this were the last page. 


FOIL 28 — First Gr&de TjgX; Title page input - 3 
Last, the paragraph of text is set at the bottom of the page. 
l£X’s Help Facility 

*\Bey 

! Undefined control sequence. 

<*> \Bey 

y y 

Type <return> to proceed, 

S to scroll future error messages, 

R to run without stopping, Q to run quietly, 

I to Insert something, 

1 or ... or 0 to Ignore the next 1 to 0 tokens of Input, 
H for help, X to quit. 

? h 

The control sequence at the end of the top line 
of your error message was never \def *ed. If you have 
misspelled it (e.g., *\hobx'), type ‘I* and the 
correct spelling (e.g., *I\hbox’). 

Otherwise just continue, and I'll forget about 
whatever was undefined. 

? i\bye 
[13 


FOIL 29 — TfeX gives some help with errors. 

When TfeX finds an error, it usually tells you about it and 
will offer what help it can. This foil shows an encounter 
with a control sequence that hasn’t been defined (actually, 
in this case, a misspelling). A menu of actions is available. 
The user can insert a temporary fix, delete some tokens, tell 
T^X to ignore the error, or ask for more information, as 
here. If T^X is reading an input file at the time, in most 
installations it will also offer to return you to your editor at 
the point of the error in the file. Here, the correct spelling 
was inserted and TfeX completed the page. 
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Typing 
Math Formulas 



FOIL 30 — Display Math Mode; Title page of 
Chapter Sixteen of The TfeXbook. 

One of TfcX’s original purposes was to provide high quality 
mathematical typesetting. 

Samples of Display Math Input 



Plain 

XMS-lteX 

a 

1 + 6 

MfaNatop l+b>M 

MVatack a{l+b>$| 

(r) 

t${n+l\choose k>M 

M\binom {n+l}k$| 

c + d 

M<a+b\ovtr c*d}|$ 

MVfrac U-bHc-d}« 


FOIL 31 — Display mode; macro packages. 

Recall that material to be set in math mode was enclosed 
in $ signs. Such material simply appears in line with 
surrounding text. Material enclosed by double $ signs is set 
in display math mode, separated from the adjacent text. In 
mathematical articles, this is usually done with important 
results and equations. l)g*X can number such equations for 
you automatically if you wish. 

Three display-math expressions appear in this foil. The 
displayed output is shown in the left column, while the 
rightmost two columns show the input as typed in two 
different dialects of TfeX. The center column shows the 
input as it is typed in plain, ttx, the vanilla-flavored IfeX. 
plain.tax is actually a file containing Knuth’s working 
macro definitions, normally preloaded by INITEX. It is 
documented completely in an appendix of The TfiXbook. 

The righthand column repeats the input under the 
circumstance that the macro package called has 

also been loaded (either dynamically or in the preload). 

^ a macro package designed by Michael Spivak 
at the request of AMS to make it easy for authors and 


editors to create material that TfcjX will typeset in the 
AMS publishing style. is extensive system of 

macro commands which builds on plain.ttx and which is 
well-documented in the publication The Joy of 3JgX, also by 
Spivak (of which a new edition will be available in a few 
weeks). As AxS-T^X becomes available at universities and 
other hotbeds of mathematical authorship, AMS hopes to 
receive an increasing number of manuscripts on tape in the 
form of already-tested and composed TfcX input. 

Another complaint against TfeX noted in the Seybold 
review is that TfeX’s vocabulary is mathematical. Notice 
in the plain.tox input that terms are employed that a 
mathematician would use naturally but which are alien to 
a typist. That is, the typist must know how to read the 
expression in mathematical terms in order to type it. Yet, if 
mathematics is to be typed by a non-mathematician typist, 
then the typist must learn some language in which to express 
it. Most typists seem to come to terms fairly easily with 
TjgX’s language. And of course, mathematicians who turn 
to TfeX to compose their own work need no introduction to 
the language'at all. 

And finally, as the third column shows, the vocabulary 
can be redefined as you like it. Spivak has done so in 
these cases, as anyone may for his own purposes. If you do 
redefine commands like this, or if you define any macros at 
all for your own use, then, if you send me your input file to 
be TfeXed on my system, the only requirement is that you 
must also send me all your macro definitions. But if you use 
only plain, tox, or only plain.tax and or only 

plaln.tex and some other macro package which we both 
share, you need send me only your text input. 

Fences 

M\lef t\{\vbox to 27pt{}\laft\{\vbox to 24ptO 
\left\{\vbox to 21ptO\Blggl\{\blggl\{\Bigl\{ 
\bigl\{\{{Vscriptityle\{{ 

\scriptscriptstyla\<\hskip3pt\»\»\>\bigr\> 

\Bigr\>\biggr\>\Biggr\>\right\>\right\>\right\>$| 

produces 



FOIL 32 — Fences 

Another example of what TfeX can provide in display mode is 
this expandable character. The input shows some versions of 
the brace which are large enough to require piecing—straight 
segments are inserted between end and center parts—as well 
as some called as characters from a font. \Biggl{ is a 
bigger left brace than \blggl{, \Bigl{ is next smaller and so 
on. \scriptstyle and \scriptscriptityle invoke fonts that 
TfeX would use automatically if it were setting subscripts 
of sub-subscripts. TfeX will do the same thing with other 
fences, like tt (* and 
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Other Extendable Symbols 

||\sqrt{i*\sqrt{l*\sqrt{l«Asqrt<l+ 

\sqrt{l*\sqrt{l+\sqrt{l+x»»>}}$| 

produces 


\ 


1 + 


N 


1 + ^1 + \Ji + \/i + Vi + >/i+~i 


A Table 

The table 

\rm \sl \it \tt \bf 

Roman Slanted Italic Typewrit tr Boldface 

is the result of the following input (the control sequence 
\\ for backslash is assumed to be defined already) 

ttXvbox {\tt \halign <\hf il #\hf 11 ft* 

\quad \hfll # \hf 11 \cr 
Wrnft Wslft Witft Wttft \\bf\cr 
\rm Roman* \sl Slanted* \lt Italic* \tt Typewriter* 
\bf Bold?actXcr 

»$* 


FOIL 88 — And other extendable symbols 

The largest two of these radical signs are made up of 
extendable pieces. 

Other Mathematical Expressions 


o 0 + 


oi + 


02 + 


1 

03 + — 
0 4 


typed as 


Ma.O+{a\over\dlsplaystyle a.l+ 
{\strnt l\over\dlsplaystyle a_2+ 
f\strut lXoverXdieplayotyle a_3+ 
fXstrut lXoverXdieplayotyle a_4»»$$ 


looks better than 


o 0 + 



which is what you get without Xstrnt and 
Xdisplaystyle. 

FOIL 84 — And mathematical expressions 

Left alone, TfeX would set the expression at the bottom 
of this foil, thinking that the denominator fractions should 
decrease in size to stay more or less in line with the 
expression which starts the denominator. This would be 
correct if there were only two levels of fraction involved. 
Here, however, esthetics call for maintaining one size 
throughout the expression. The \strut produces an 
empty box the proper height to make *I)g*X leave enough 
vertical space to set a full-sized fraction, and the command 
\displaystyle forces IfeX to use full-sized characters when 
it would automatically drop into \scriptstyle or smaller. 


FOIL 86 — And tables. 

Here's a fairly simple, two-line example of a table set by 
lfcjX. The table itself shows the control sequence names 
which call for various typefaces within a font family. \bf, 
for example, causes TfcjX to shift to the boldface style of 
the current font. 

A table is set within a vertical box in display math, 
using the \hallgn macro for table construction. The 
\halign looks first for a template on which to base the table 
structure. Here, the template begins with \hfll #\hfll, 
showing that the first column of the table will have an 
element, represented in the template by #, surrounded 
by expandable horizontal space—that is, centered in the 
column. The next element in the template is an &, marking 
the end of the format for that column. The second & 
immediately following the first tells tex that the format for 
the next column is to be repeated as many times as the table 
requires. These are all just like the first column, except that 
they begin with a \quad of space (equal to one em). The 
\cr signals the end of the template. 

The next line of input is the first row of the table. It 
puts the text “\rm” in the first column. The & following 
marks the end of input for that column. The row continues 
until the \cr. The second row enters the words “Roman”, 
“Slanted”, etc., in the appropriate columns, each in the 
appropriate typeface (overriding the \tt command at the 
beginning of the input, which caused all the entries in the 
first row of the table to appear in typewriter font). 

The table input ends with grouping symbols which 
close the \halign macro, the \vbox macro, and the display 
mode. 

This table was easy, and the concept is quite straight¬ 
forward. But people can think up devilishly complicated 
table formats, with subdivided columns containing an as¬ 
sortment of text, multi-column headers, and so on. All these 
are possible to generate in TfeX, but the input can require a 
good deal of thought. It will be very useful to TfeX users 
everywhere when someone writes a macro package which 
uses these features of TfeX to simplify the construction of 
complex tables. 
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VI. Document Formatting 

Document Formatting with IATjgX 

1 . An enumerated list, like this one, is created with the 
•nunerate environment. 

2. Enumerations can be: 

(a) Nested within one another, up to four levels deep. 

(b) Nested within other paragraph-making environ¬ 
ments. 

3. Each item of an enumerated list begins with an \ltea 
command. 

is produced by 

Vheglnfenunerate} 

\ltem in •numerated list, like ... 

\item Enumerations can be: 

\begln<enumerate> 

\ltem Nested vlthln one another ... 

\ltem Nested vlthin other ... 
\end{enumerate> 

\item Each item of an ... 

\ond<enumerate> 
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Output Routines 



FOIL 36 — IATfeX; A sample. 

The AmS-T^X macro package provides extra-powerful com¬ 
mands for typesetting a wide variety of mathematical 
constructions. It does not include document formatting 
commands of the sort provided by Scribe or Runoff or 
Script. Leslie Lamport, at SRI, has written a macro package 
called iATfeX which does provide such commands. Like 
all other TfeX macro packages, LAI^jX need only be called 
dynamically or preloaded with IfeX to make its commands 
available to you. 

This foil shows one example of the sort of command 
available with IAT^jX. This is a Scribe-like command called 
^enumerate” which produces a nicely formatted list. 
IATjfcX adds many powerful document processing commands 
to TfeX, greatly simplifying the formatting of business 
documents such as letters, reports, and manuals. The 
IATJ«*X manual will be published shortly by Addison-Wesley. 

The authors of 4 m$- 1&X and IATfeX have collaborated, 
and they may eventually combine these two packages into 
one, perhaps called L^mS-T^X. Then again, that task may 
be left to some other ambitious TfeX user. 

Another significant task awaiting the touch of an 
experienced TJjjX user (that is, some TfeXpert) is the 
creation of Bookl^X, a macro package which will give 
professional book designers the pointed tools they need 
to create beautiful books. The designing of books takes 
very different skills from those needed for the creation of 
beautiful mathematics. Richard Southall is an eminent book 
designer at the Department of Typography and Graphic 
Communication at the University of Reading, in England, 
who has worked with Knuth. Southall asserts that no 
one has yet made a beautiful book with TfeX because its 
commands, and those of most TfeX macro writers so far, 
reflect the computer scientist’s need for generalization rather 
than the graphic designer’s understanding of beauty. So 
who will write the BooklJ^X macro package? The world 
awaits. 


FOIL 37 — Output routines; Title page, Chapter 23 
of The 7&Cbook. 

One final aspect of TfeX should be mentioned, plaln.tex 
produces actual output in the form of pages, with numbers 
centered at the bottom and no running heads. Often, a 
different or more elaborate output format is needed. 


The problem of document design 
for computer-based systems 

In the past, the design of 
documents was done a posteriori. 
Books were written before they 
were designed: the conceptual 
structure of the author's thoughts 
was already in place, embodied in 
some graphic form or other, and 
the designer’s task was to render 
or re-render that embodiment 
in a semantically effective and 
technically practicable way. 

In the design of documents 
for computer-based document 
production systems, the problem 
is the other way round. The 
document has to be designed 
a priori, before the author’s 
thoughts are present at all. 
The document designer’s task 
is to devise efficient graphic 
embodiments for conceptual 


structures that are suitable to 
fit any thoughts that any author 
using the system might have. 

The document designer 
cannot tell (let alone dictate) 
what content an author will 
put into each of the conceptual 
structures that the document 
design provides for, or in what 
order the structures will be 
used. It is not too hard to 
provide a graphic embodiment 
for each structure, that will 
behave reasonably if it is not 
used in what its designer would 
consider to be an unreasonable 
way; but what is unreasonable to 
a document designer may not be 
at all so to a mathematician or a 
philosopher. 

Richard Southall 


FOIL 38 — The results of one output routine. 

This foil shows material formatted by an output routine 
that divides the material into two, right-justified columns. 
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The problem of document design for computer-bued systems 

In the past, the design of documents was done a posteriori. 

Books were written before they were designed: the conceptual 
structure of the author’s thoughts was already in place, embod¬ 
ied in some graphic form or other, and the designer’s task was to 
render or re-render that embodiment in a semantically effective 
and technically practicable way. 

In the design of documents for computer-based document 
production systems, the problem is the other way round. The 
document has to be designed a priori, before the author’s 
thoughts are present at all. The document designer’s task is to 
devise efficient graphic embodiments for conceptual structures 
that are suitable to fit any thoughts that any author using the 
system might have. 

The document designer cannot tell (let alone dictate) what 
content an author will put into each of the conceptual struc¬ 
tures that the document design provides for, or in what order 
the structures will be used. It is not too hard to provide a 
graphic embodiment for each structure, that will behave rea¬ 
sonably if it is not used in what its designer would consider to 
be an unreasonable way; but what is unreasonable to a docu¬ 
ment designer may not be at all so to a mathematician or a 
philosopher. 

Richard Southall 

FOIL 39 — The results of a different output routine. 

Here is the same material with a change in the output routine 
definition. Macro packages such as plain.ttx and AxS-lfeX 
and IATfcjX provide only fairly simple and standardized 
output routines. AmS -TfeX offers only a “preprint” output 
format, suitable for typesetting mathematical papers in a 
generalized form. The AMS, however, when it publishes 
a paper created by AxS-TfeX, will include special output 
routines for the specific target journal. TfeXperts at 
installations where TfeJC is in use will ordinarily create 
output routines specialized to local needs. 


VII. A little more about METAFONT 

4 

Fonts 
of Type 



FOIL 40 — Fonts; Title page of Chapter Four of The 
T&Cbook. 

Fonts are an important part of TfeX usage. One manu¬ 
facturer, Autologic, has decided to place all the fonts that 
come with the TJjpC distribution tapes into its machines 1 
font memories. In effect, Autologic used the .PXL files 
to create new Autologic fonts that can be ordered with 
their machines. That means you needn’t have those .PXL 
files on your system. The programs that translate .DVI 
files into Autologic commands simply identify a character 
in the purchased fonts, rather than transmit a .PXL raster 
pattern. I understand that Autologic has also created .TFM 
files for its own proprietary fonts, so that T)$X can also 
use existing Autologic fonts. There are those who think 
some of Autologic’s fonts are nicer than TJgjX's Computer 
Modern Roman, so this is a useful advance, as well as 
a simplification. Other manufacturers may follow suit, 
especially if use of TfeX becomes widespread. 


Character Box as Interpreted by T^jX 



FOIL 41 — TfeX’s character. 

Here is TfeX’s idea of a character. It is surrounded by a 
box, although it can sometimes stick out of the box. The 
box has a width and it has a reference point which sits on 
the baseline. It has a height extending above the baseline 
and a depth descending below it. The .TFM files contain 
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just these box dimensions, pins some kerning information, 
the amount of extra spacing to be left if the character sits 
next to one from a slanted font, and, in the case of math 
symbols, some other positioning and spacing information. 
These font metric files don’t have any information about the 
shape of the character itself at all—that is to be found in 
the raster patterns of the .PXL files. METAFONT creates 
both kinds of file—the .TFM and the .PXL. 

METAFONT Proof Output - The Letter U 



FOIL 42 — METAFONT proof output for the 
character “IT. 

Here is an example of METAFONT input and output for 
the character “U” . Relatively few points are required. Here 
the font designer has picked 7 positions along the letter, 
with three points—one on the left edge, one in the center, 
and one on the right edge—to be entered for each position. 
To generate this proof copy, METAFONT creates a .DVI 
file using a font called “the gray font”, simply a collection 
of pixels at various resolutions, two of which are shown 
here. The points selected by the METAFONT user on the 
designer’s original drawing are shown with the output. 


METAFONT Input - The Letter U 

vurdtf char .U c 
•etwidth .75tm; 

poel(1. lthlckvldth, 10) ; X pen starts slightly thick 
pos2(thlckvldth.10); 
pos3(thlckvldth,40); 
pos4(.6[thlckvldth,thlnvldth],76); 
pos6(.9[thickwldth,thlnvldth],130); 
posfiCthinwidth, 180) ; X nov It's "thin", turned over 
pos7(1.lthlnvldth,190); 

xll*.lem; x71*w-. ltm; X there are sidebars of .lem 
yl=y7*caphtight; X have nov fully specified 1 and 7 
x2=xl; y2*.3capheight; d*2*(0,-l); 
x3*.76[x4,x2]; y3*.76[y2,y4]; X see btlov! 
x4r*.6[x2r,x6r]; y41*-.05caphelght; di4*(l,0); 
x5 s .71[x4,xfi]; y6*.71[yfi,y4]; X see below! 
x6=x7; yfi=l/3capheight; dad*(0,1); X going up at 6 
stroked,2. .2, .06. .05) ; X make a very slight taper 
curve (2,3,4); curve (4,6, d) ; X curve the bottom 

stroke(d.7, .8, .06. .06); X finish somewhat as at left 
labelpos(l,2,3,4,6,d,7) ; X list all positions 
enddef; 

FOIL 48 — The METAFONT input for “IT. 

METAFONT is given pen size and shape instructions for 
each position, along with a few other instructions on some 
details of the character’s shape. From these, METAFONT 
creates the raster image and the metric data for the 
character. METAFONT is designed so that the same input 
with only minor changes will create the same character in 
different sizes and typefaces, thereby generating whole font 
families from the same original design almost automatically. 


Hjgng 

ij§J! 

ms 

mm 

mm 

E 

mm 


pi 

METRFONT 

Mi 

H 

Hi 

MPlS 

Si 

up 

■m 

fSi 

Si 

m 

Bi 


William Burley 


FOIL 44 — A METAFONT border. 5 

Last Spring at Stanford, Knuth offered a course in designing 
fonts with METAFONT. As one exercise, he asked each 
student to create a font of eight characters: four characters 
which could serve as the extensible edges of a large border 

and four others which would connect the edges to make the - 

corners of the border. Here the resulting effect is something 5 Borders are reproduced from [TUB], Vol. 5, No. 2, 

akin to the Greek Key. November 1984, pp. 106-118. 
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METflFO 


aa 


Arthur Samuel 


FOIL 45 — A Second METAFONT Border example. 

Arthur Samuel, author of First Grade IfeX, was one of the 
students. He provided a neat, conservative example. 



FOIL 40 — A third METAFONT Border. 

This border enclosed the student’s name instead of the 
METAFONT logo (Joey Tuttle is vice president of T)EjX 
Users Group). These are pretty fancy characters. 



FOIL 47 — A fourth METAFONT border. 


As are these. 






























FOIL 49 — The METAFONT Class Picture ‘ 

And then they made an italic font and took a picture of 
that. 


* Photo by Jill Knuth; reprinted from [TUB], Vol. 5, 
No. 2, November 1984, p. 109. 
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A Sample of Fonte Included in PLAIN. TEX 


AMR10, AMRO.AMR5 Roman: ABCDefgh 

AMMI10. AMMIO.AMMI5 “Math italic”: 

ABCDefgh re\ 

AMST10, AMSTO.AMST5 Symbols: X6 n U()oo • II 

AMEX10 Oversized and pieced 

symbols: | 

AMBX10, AMBXO.AMBX5 Boldface: ABCDefgh 

AMTT10. AMTTO. AMTI8 “Typewriter”: ABCDefgh 

AMSL10. AMSLO, AMSL8 Slanted: ABCDefgh 

AMTI10, AMTIO.AMT 17 Text italic: ABCDefgh 

AMSSIO Sans serif: ABCDefgh 

AMSSBXIO Bold sans serif: 

ABCDefgh 


At the request of the AMS, Herman Zapf, a pre-eminent 
font designer, undertook the design of a family of special 
mathematical fonts which he named Euler in honor 
of Leonhard Euler, a famous Eighteenth Century Swiss 
mathematician. These are some of the designs included in 
the Euler family. The fraktur and script fonts shown here 
are examples of Zapf’s work. 


VIII. The TfeX Users’ Group 

j 


FOIL 50 — Some of the fonts included on the 
standard distribution. 

Knuth’s original fonts were called Computer Modern Roman, 
or CMR. He is enlisting the help of some of the world’s most 
noted font designers to improve these fonts’ appearance. 
He expects to perfect the fonts in three stages, the first 
improved version being the AMR fonts. Next will come the 
BMR fonts, and finally, next year, we’ll have CMR fonts 
again. This foil gives examples some of the current standard 
fonts. 

Additional Fonts Created at AMS 

Fraktur: 

!8 2 + 0 s + !Jl 4 = <P(3t) 

Script: 

+ S 8 + x 4 = 3>(X) 

Cyrillic: 

MemaHCKHft ymmepcHTeT, HaxoRxmHftcH Ha nyTH 
k HecicyHHOMy, npaaRHOBan Ha rhhx cboI* 
nxTHRecjiTHJieTHHft lo&iHeft. Koro boshjih b Thtbi 
HJ1H ropORCKyiO 6o;ibHHHy, TOT, KOHeHHO, IIOMHHT 
SROpOBeHHeftUIHft, TpeX»Ta3KHblft ROMHIRe no 
npaByio pyicy c BMBecicoft «BoraRem*Haa h 
M em&HCKHe yHHJiHiRe> h TOMy HaBepHoe 
BCTpenaJiHCb Ha nyTH sepeHHRBi yueHHHecKHX nap, 
cojihrho nporynHBaeMLix HaRSHpaTejiaMH. 

FOIL 51 — Samples of Euler and Cyrillic. 


Joining the 
T^X Community 



FOIL 52 — The TfeX community; Title page of 
Appendix J of The TfiXbook. 

Richard Palais was instrumental in bringing to life the 
organization known as TUG, the TfeX Users Group. TUG’s 
purpose is to provide a forum for the exchange of information 
among TfeX users by means of meetings and courses and 
a newsletter and other publications. TUG commissions 
expert TfeX users to create useful macro packages, reference 
documents, and teaching materials. TUG provides TfcXperts 
to teach courses in TfeX usage at various companies and 
academic institutions. TUG expects soon to provide hotline 
assistance to people who need help installing and using TfeX. 
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FOIL 53 — Cover of TUGboat, Vol. 1, No. 1 

TUG’s newsletter is, of course, called TUGboat. TUGboat 
is published two (and we hope, starting next year, three) 
times a year and contains useful articles by both the 
developers and the users of TfeX and METAFONT. Knuth 
contributed to the most recent issue the interesting article 
on the METAFONT course from which my earlier foils 
were taken. New macro packages are published there, along 
with information about versions of TfeX ported to new 
systems and the use of new output devices. TUGboat is 
edited by Barbara Beeton, the senior T^Xpert at the AMS, 
who helped with many of the details of this presentation. 
She has now published in TUGboat many articles received 
from authors as TfeX input on tape, bringing Palais’ original 
hope closer to reality. 

MacKAY, Pierre A. 

Dept of Computer Science 
Univ of Washington 
FR-35 

Seattle. WA 98195 

206-545-2386 

Arpanet. MacKayQWashington 
Adjunct Professor of Computer Science 
Computer: VAX 11/780. 11/750 (UNIX): 

DEC 2060: CDC Cyber 170-750 
Output device(s): Versatec: Alphatype CRS; 

III VideoComp: Symbolics LGP-10 
Appiications: Arabic and similar character sets 


Along with each issue of TUGboat come a list of all the 
corrections found to date to The T^jKbook and a current 
membership list containing the names, addresses, phone 
numbers, and hardware of every member of TUG. This 
entry is that of the TfeX Users Group president Pierre 
MacKay of the University of Washington, but all entries 
are as complete. TUG’s $20 annual individual dues include 
a subscription to TUGboat. There are now about 1100 
individual, and about 75 institutional, members of TUG. 

TgX Users Group Membership List 

Contents 

Site Coordinators, Steering Committee and 
members of other TUG Committees 
Institutional Members 
Addresses of TUG Members 
Member names listed by institution 
Member names listed by computer 
Member names listed by output device 
TfeX consulting and production services for sale 

FOIL 65 — Structure of Membership list 

Site coordinators are experts in versions of 1feX on specific 
hardware systems. They will give you free advice on 
installation, bugs, changes, problems in that version. They 
are sources of information on output devices and drivers. 
They may be suppliers of tapes for that version, as well 
(i.e., MacKay supplies the VAX/Unix version of T^X) at a 
nominal cost. Kellerman k Smith (listed in the directory) 
supply a VAX/VMS version with several output drivers not 
available on vanilla tapes. 

TUG’s committees are charged with improving the TfeX 
environment by, e.g., soliciting manuscripts for improved 
documentation, new macro packages, user aids, etc. 

Members are listed by institution, by hardware system, 
and by output device. 

TUGboat carries notices of available TJgX services, as 
well. Some service bureaus now exist solely to provide 
Tfc*X services. Tyxset, in Reston, VA., is one mentioned 
in the Seybold Report. Textset, in Ann Arbor, Michigan, 
is another which markets TfeX on both Apollo and Sun 
workstations with programs that allow the user to view to 
composed output on the screen. Others are running TfeX 
on various PC’s. Anyone can contact these service bureaus 
directly to inquire about particular services and costs. 

T^X Users Group meetings are held annually, at 
Stanford at least through 1985. At these meetings, Knuth 
and his TJgjX associates describe the latest and projected 
TfeX developments and hear suggestions and questions from 
the user community. Very many of TfeX’s present features 
have resulted from the dialog at meetings. Beginning and 
advanced TfeX courses are given at the meetings as well as 
regionally. 


FOIL 64 — A sample directory entry 
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TgX Uwn Croup 


1065 


Membrahlp/Order Form 


RtquMt for Information 

The 1£X Useis Group maintains • databa a r and 
pubiiabaa a m embe rsh ip list containing information 
about the equipment on which m em ben organiza¬ 
tion* plan to or have metalled TLX. and about the 
applications for which TLX would be uaed 

Pleaoa anower the questions below, in particu¬ 
lar tboar regarding the status of TLX and the com¬ 
puter!* I/operating system!*) on which it runs or is 
being installed (Eapecially for IBM and VAX. the 
operating system is more relevant than the model ) 
If it baa not yet been dooe for your site, please 
also sarmr the questions about output devices on 
tbe other aide of this fora, obtaining information 
from tbe moat knowledgeable person at your instal¬ 
lation if nsceaaary. If this information has already 
been provided by another TUG member, please in¬ 
dicate that member's name, and the information 
will be repeated If you need more apace than is 
provided here, feel free to use additional paper 
If your current luting is correct, you need not 
anower tbsse questions again Your cooperation is 
appreciated 


21* 

ITEM j 

AMOUNT 


1965 TUGboat Subscription/TUG Membership (Jsn -Dec.) North America 

New (first-time) 1 ) 120 00 each 

Renewal { |t30t)0 [ j 320 00 - reduced rate if renewed before January 31.1985 



1965 TUGboat Subscription/TUG Membership (Jan -Dec.) - Outside North America* 

New (first-time): I j S25 00 each 

Renewal i ) S3S.00. { 1125 00 - reduced rate if renewed before January 31.1965 



TUGboat back isauea. fIS 00** 1960(v.l) 1961 (v. 2) 1982(v 3) 1983 (v 4) 1964 (v.5) # 1. #2 
per issue, circle iasue(a) desired #1 #1.#2,#3 #1.#2 #1. #2 (after 12/31/M) 



First Grade TfcX A Beginner'* 7£X Manual by Arthur L Samuel 96.00 each 


User's Guide to tbe HP 7fc\ Macros by Susan Daniel* 96 00 each ! j 


TLX and Metafont Errata and Changes (final edition. September 1983) 94.00 each j 1 


The TLX book Errata and Change* (included with TUGboat) - additional copies 93.00 each j | 


TfeX Lectures on Tape (Prices reduced - see cover 3. Vol 5. No 2) j 

i ii 


* Air mail postage is included in the rates for all subscriptions 

and memberships outside North America TOTAL ENCLOSED _ 

** Dwcount 5 1 copies lOTt 8 or more. 15*5t (Prepayment in US dollars required) 


a Send completed form with remittance 
(checks, money orders, unesco coupon*) to 
TfcX Users Croup 
P O Boa MM 

Providence. Rhode Island 03901 U S A 
a For foreign bank transfer? 
direct payment to tbe TLX User* Group, 
account #002-610671. at 

Rhode Island Hospital TYust National Bank 
One Hospital Trust Plata 
Providence. Rhode Wand 03903-2449. USA 
a General correspondence 
about TUG should be addr es sed to: 

T£X Uam Group 
P O Box 9606 

Providence Rhode Wand 03940-950b t S A 



erahip Lint Information 


Institution (if not part of addreas) 

Title 

Phone 

Specific applications or reason for interest in TLX 

My installation can offer the following software or 
technical support to Tl'G 


Please list high-level TLX users st your site who would not mind 
being contacted for information, give name, address, and tele¬ 
phone 


Date 

Status of IfeX | i Under consideration 
| Being installed 
! ] Up and running since 

Approximate number of users: 

Version of 1 )eX: ; j SAIL 
Pascal i I TfcN82 | [ TLX 80 

| Other (describe) 

From whom obtained 

Computer(s) and operating system(s) 


FOIL 66 — The TUG Order Form, a table set by 

TfeK. 

This is an example of a much more complex table, set by 
TfeX. The TUG order form lists most TJgX publications, as 
well as details of membership. 

TfcX has, in fact, set new directions in computer 
typesetting. It really can provide a typesetting facility for 
almost everybody: a full ability to generate top quality 
typeset output is now in the hands of everyday people for 
everyday use. When one understands something of TfcjX’s 
power, it is tempting to agree with Gordon Bell, then a 
Digital vice president, when he said, in his introduction 
to Knuth’s book, IfeX and METAFONT, New Directions 
in Typesetting , “Don Knuth’s Tau Epsilon Chi (TfeX) is 
potentially the most significant invention in typesetting in 
this century. It introduces a standard language for computer 
typography and in terms of importance could rank near the 
introduction of the Gutenberg press.” 


For more information regarding TfejX or the TfeX Users 
Group, write or call Ray Goucher, Business Manager, 
TfcjX Users Group, P.O. Box 9506, Providence, RI 02940, 
401-272-9500, ext. 232. 


References 

[ACP] Knuth, Donald E., The Art of Computer 
Programming, Addison-Wesley, VoL 2, 1969 and 
1981 editions. 

[MT] Knuth, Donald E., “Mathematical Typography”, 
Bulletin (New Series) of the American Mathematical 
Society 1 (1979), 337-372. 

[T&M] Knuth, Donald E., TfeX and METAFONT, 

New Directions In Typesettings Digital Press and the 
American Mathematical Society, 1979. 

[CM] Knuth, Donald E., Tbe Computer Modern Family of 
Typefaces , Stanford Computer Science Report 
STAN-CS-80-780 (January, 1980). 

[LP] Knuth, Donald E., Literate Programmings Stanford 
Computer Science Report STAN-CS-82-981. 

[TB] Knuth, Donald E., The 1 feXbook, Addison-Wesley 
and the American Mathematical Society, 1984. 

[MB] Knuth, Donald E., The META FONT book, 
Addison-Wesley, 1985 (in preparation). 

[LaTeX] Lamport, Leslie, The IATfeX Document 
Preparation System, Addison-Wesley, 1985 
(in preparation). 

[FG] Samuel, Arthur, First Grade TfcX, TfeX Users Group, 
1984. 

[RS] Southall, Richard, “First principles of typographic 
design for document preparation”, TUGboat , Vol. 5 
(1984), No. 2, pp. 79-90. 

[Joy] Spivak, Michael, The Joy of 3feX, the American 
Mathematical Society, 1980, new edition in 
preparation, 1985. 

[Sey] TJgX On A Microcomputer, The Seybold Report on 
Publishing Systems, Vol. 14, No. 4, (Oct 29, 1984), 
Seybold Publications, Inc. 

[TUB] TUGboat , the Newsletter of the IJgX Users Group , 
IfeX Users Group, c/o American Mathematical 
Society, P. O. Box 9506, Providence, RI, 02904. 
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TUGboat, Volume 5, No. 1 


TgX82 ORDER FORM 






l 


The latest official versions of TJsX software and documents are avail¬ 
able from Maria Code by special arrangement with the Computer Science 
Department of Stanford University. 

Nine different tapes are available. The generic distribution tape con¬ 
tains the source of TgX82 and WEB, the test program, a few “change” files, 
the collection of fonts in tfm format, and other miscellaneous materials; a 
Pascal compiler will be required to install programs from a generic tape. 
The ^5-lEX macro package is included on the T£X distribution tapes; other 
macro packages, including I?TeX and HP TeX, will be added as they become 
available. The special distribution tapes are for the indicated systems only, 
and should be ordered for these systems instead of a generic tape. Two tapes 
are pxl font collections covering various magnifications at 200/240 dots/inch 
and 300 dots/inch respectively. The Metafont tape contains the SAIL 
source for the Metafont program and includes the .mf source files. 

Each tape will be a separate 1200 foot reel which you may send in advance 
or purchase (for the tape media) at $10.00 each. Should you send a tape, you 
will receive back a different tape. Tapes may be ordered in ASCII or EBCDIC 
characters. You may request densities of 6250, 1600 or 800 (800 is discouraged 
since it is more trouble to make). 

The tape price of $82.00 for the first tape and $62.00 for each additional 
tape (ordered at the same time) covers the cost of duplication, order process¬ 
ing, domestic postage and some of the costs at Stanford University. Extra 
postage is required for first class or export. 

Manuals are available at the approximate cost of duplication and mailing. 
Prices for manuals are subject to change as revisions and additions are made. 
It is assumed that one set of manuals will suffice you. If you require more 
than two sets, please write for prices since we must ask for more money for 
postage and handling. 

Please send a check or money order (payable on a US bank) along with 
your order if possible. Your purchase order wifi be accepted, as long as you 
are able to make payment within 30 days of shipment. Please check this out 
before sending a purchase order since many large firms seem to be unable to 
make prompt payment (or don’t worry about it). 

The order form contains a place to record the name and address of the 
person who will actually use the 1 feX tapes. This should not be someone in 
the purchasing department. 

Your order will be filled with the most recent versions of software and 
manuals available from Stanford at the time your order is received. If you 
are waiting for some future release, please indicate this. Orders are normally 
filled within a few days. There may be periods (like short vacations) when it 
will take longer. You will be notified of any serious delays. If you want to 
inquire about your order you may call Maria Code at (408) 735-8006 between 
9:30 a.m. and 2:30 p.m. West Coast time. 

If you have questions regarding the implementation of IgX or the like, 
you must take these to Stanford University or some other friendly TfiX user. 

Now, please complete the order form on the reverse side. 


TUGboat, Volume 5, No. 1 


TeX82 ORDER FORM 

** TAPES ** density (6250, 1600 or 800) = _ 

T£X generic distribution tapes (Pascal compiler required): 

_ ASCII format _ EBCDIC format 

T£X distribution tapes in special formats: 

_ VAX/VMS Backup format _ IBM VM/CMS format 

_ DEC 20/Tops-20 Dumper format _ * IBM MVS format 

♦ Not yet available; call before ordering 

Font tapes: 

-- Font library (200/240 dots/inch) _ Font library (300 dots/inch) 

_ Metafont (SAIL compiler required) 

_ Total number of tapes. 

Tape costs: $82.00 for first tape; $62.00 for each additional. 

Tape cost = $ _ 

Media costs: $10.00 for each tape required. 

Media cost = $ _ 

** MANUALS ** 

_ TgX82 - $20.00 _ Test Manual - $8.00 

_ WEB-$10.00 _ TEXware - $8.00 

_ TgXbook - $20.00 _ BIgX (preliminary edition) - $8.00 

Manuals cost = $ _ 

California orders only: add sales tax = $_ 

Domestic book rate: no charge. 

Domestic first class: $2.50 for each tape and each manual. 

Export surface mail: $2.50 for each tape and each manual. 

Export air mail to North America: $4.00 each. 

Export air mail to Europe: $7.00 each. 

Export air mail to other areas: $10.00 each. 

Postage cost = $_ 

(make checks payable to Maria Code) Total order = $_ 

Name and address for shipment: Person to contact (if different): 


Telephone_ 

Send to: Maria Code, DP Services, 1371 Sydney Dr., Sunnyvale, CA 94087 


5/84 
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TJjjX Users Group 


1985 


Membership/Order Form 


Request for Information 

The IgX Users Group maintains a database and 
publishes a membership list containing information 
about the equipment on which members’ organiza¬ 
tions plan to or have installed and about the 
applications for which TfcX would be used. 

Please answer the questions below, in particu¬ 
lar those regarding the status of IfeX and the com¬ 
puters)/operating system(s) on which it runs or is 
being installed. (Especially for IBM and VAX, the 
operating system is more relevant than the model.) 

If it has not yet been done for your site, please 
also answer the questions about output devices on 
the other side of this form, obtaining information 
from the most knowledgeable person at your instal¬ 
lation if necessary. If this information has already 
been provided by another TUG member, please in¬ 
dicate that member’s name, and the information 
will be repeated. If you need more space than is 
provided here, feel free to use additional paper. 

If your current listing is correct, you need not 
answer these questions again. Your cooperation is 
appreciated. 


• Send completed form with remittance 
(checks, money orders, UNESCO coupons) to: 

IfeiX Users Group 
P. O. Box 594 

Providence, Rhode Island 02901, U.S.A. 

• For foreign bank transfers 

direct payment to the T^JX Users Group, 
account #002-610871, at: 

Rhode Island Hospital Trust National Bank 

One Hospital Trust Plaza 

Providence, Rhode Island 02908-2449, U.S.A. 

• General correspondence 

about TUG should be addressed to: 

T^X Users Group 
P. O. Box 9506 

Providence, Rhode Island 02940-9506, U.S.A. 


Name:_ 

Home ( ) . J , 

Bus. [ ] Address: 


qty 

ITEM 

AMOUNT 


1985 TUGboat Subscription/TUG Membership (Jan.-Dee.) - North America 

New (first-time): [ ] $20.00 each 

Renewed: [ ] $30.00; [ ] $20.00 - reduced rate if renewed before January 31,1985 



1985 TUGboat Subscription/TUG Membership (Jan.-Dee.) - Outside North America* 

New (first-time): [ j $25.00 each 

Renewal: [ ] $35.00; [ ] $25.00 - reduced rate if renewed before January 31,1985 



TUGboat back issues, $15.00 ** 1980 (v. 1) 1981 (v. 2) 1982 (v. 3) 1983 (v. 4) 1984 (v. 5) #1, #2 
per issue, circle issue(s) desired: #1 #1,#2, #3 #1, #2 #1, #2 (after 12/31/84) 



First Grade T£X: A Beginner’s TfejX Manual by Arthur L. Samuel - $6.00 each 



User’s Guide to the HP Macros by Susan Daniels - $6.00 each 



TgX and Metafont: Errata and Changes (final edition, September 1983) - $4.00 each 



The T^Xbook: Errata and Changes (included with TUGboat) - additional copies $3.00 each 



T^jX Lectures on Tape ( Prices reduced - see cover 3, Vol. 5, No. 2) 






* Air mail postage is included in the rates for ail subscriptions 

and memberships outside North America. TOTAL ENCLOSED: - 

** Discount: 5-7 copies, 10%; 8 or more, 15% ( Prepayment in U.S. dollars required ) 


* * * * 

Membership List Information 


Institution (if not part of address): 

Title: 

Phone: 

Specific applications or reason for interest in TgX: 

My installation can offer the following software or 
technical support to TUG: 


Date: 

Status of TfeX: [ ] Under consideration 

[ ] Being installed 
[ ] Up and running since 

Approximate number of users: 

Version of IfeX: [ ] SAIL 
Pascal: [ ] T£X82 [ ] 1^X80 

[ ] Other (describe) 


From whom obtained: 

Please list high-level TfeX users at your site who would not mind 

being contacted for information; give name, address, and tele- Computer(s) and operating system(s): 

phone. 
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HjjX Users Group 


1985 Membership Form 

Please answer the following questions regarding output devices used with T£X 
unless this form has already been filled out by someone else at your installation. 
Use a separate form for each output device. 

Name _ Institution _ 


A. Output device information 
Device name 

Model 

1. Knowledgeable contact at your site 
Name 

Telephone 

2. Device resolution (dots/inch) 

3. Print speed (average feet/minute in graphics 
mode) 

4. Physical size of device (height, width, depth) 

5. Purchase price 

6. Device type 

[ ] photographic [ ] electrostatic 
[ ] impact [ ] other (describe) 

7. Paper feed [ ] tractor feed 

[ ] friction, continuous form 

[ ] friction, sheet feed [ ] other (describe) 

8. Paper characteristics 

a. Paper type required by device 
[ ] plain [ ] electrostatic 

[ ] photographic [ ] other (describe) 

b. Special forms that can be used [ ] none 

[ ] preprinted one-part [ ] multi-part 

[ ] card stock [ ] other (describe) 

c. Paper dimensions (width, length) 
maximum 

usable 

9. Print mode 

[ ] Character: ( ) Ascii ( ) Other 

[ ] Graphics [ ] Both char/graphics 

10. Reliability of device 

[ ] Good [ ] Fair [ ] Poor 

11. Maintenance required 

[ ] Heavy [ ] Medium [ ] Light 

12. Recommended usage level < 

[ ] Heavy [ ] Medium [ ] Light 

13. Manufacturer information 

a. Manufacturer name 
Contact person 
Address 

Telephone 

b. Delivery time 

c. Service [ ] Reliable [ ] Unreliable 

B. Computer to which this device is interfaced 

1. Computer name 

2. Model 

3. Type of architecture * 

4. Operating system 


C. Output device driver software 

[ ] Obtained from Stanford 
[ ] Written in-house 

[ ] Other (explain) 

D. Separate interface hardware (if any) between host 
computer and output device (e.g. Z80) 

1. Separate interface hardware not needed because: 

[ ] Output device is run off-line 

[ ] O/D contains user-programmable micro 

[ ] Decided to drive O/D direct from host 

2. Name of interface device (if more than one, 
specify for each) 

3. Manufacturer information 

a. Manufacturer name 
Contact person 
Address 

Telephone 

b. Delivery time 

c. Purchase price 

4. Modifications 

[ ] Specified by Stanford 
I ] Designed/built in-house 
[ ] Other (explain) 


5. Software for interface device 

[ ] Obtained from Stanford 
[ ] Written in-house 
[ ] Other (explain) 

E. Fonts being used 

[ ] Computer Modern 
[ ] Fonts supplied by manufacturer 
[ ] Other (explain) 

1. From whom were fonts obtained? 

2. Are you using Metafont? [ ] Yes [ ] No 

F. What are the strong points of your output device? 


G. What are its drawbacks and how have you dealt 
with them? 


H. Comments - overview of output device 


If your computer is “software compatible” with another 
type (e.g. Amdahl with IBM 370), indicate the type here 
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An AI Project Case Study - The First Six Months 


Don Rosenthal 


The following pages are handouts from a talk given at DECUS in Anaheim. Specifically, 
you’ll find copies of the viewgraphs, and the bibliography of knowledge based systems 
(which we ran out of at the session—apologies). 

An earlier draft of the bibliography was published in the July, 1984 ACM SIGART 
newsletter by D. Sriram of the Carnegie-Mellon University Design Research Center. It 
is distributed with the permission of the author. 

Note that a follow up to the Rl paper by J. McDermott (see page 9 of the bibiography) 
entitled “Rl Revisited: Four years in the Trenches” was published in the Fall 1984 issue 
of “The AI Magazine”. 
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An AI Project Case Study-The First Six Months 


Overview 


Don Rosenthal 

Space Telescope Science Institute 
Homewood Campus 
Baltimore. MD 


• Report on first 6 months of a real-world AI project 

• "Real World**: not a research project, we're producing working sys¬ 
tems 

• Presentation will cover 

- evaluation of need for AI 

- choice of tools to meet the need 

- training to use the tools 

- early prototyping 


Aa Al Praia*. CaM Ilirfr - Tha Fim lu 


DmMM> I 1 M« 


!>«*» • Tfc# P.ra. ill Umi ha Dan |m..UiI D«»mi I IHi 


Intent of Presentation 

• To help calibrate what*s involved in starting from scatch. 

• For anyone considering AI solutions for the first time 

• This Work reported has been accomplished since last DECUS (June 
*84) 

• One person full time 


Context of Project 

• Ground support subsystems for Space Telescope 

• Specifically in planning and scheduling use of telescope. 

. Planning and scheduling includes everything from receipt of proposals 
from astronomers to generation of spacecraft co mman ds. 


■■ AI P **,*«> Cam »««4* - Th# Pint lu MmA Qua RamaiaaI D**aa>a*r 1 1**4 


A* AI Praia*. Cm* »>**» - Tha Pm. lu Maa.h* Daa RaMa.bal Oaaaataar I. INI 
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Space Telescope 


Problems in Planning and Scheduling 


• Orbiting telescope 

• Five Instruments on board designed to do astronomy 

• In addition, guidance system can be used for positional astronomy. 

• Sets of instruments can be used simultaneously. 


A* *1 Cm Six** - Th. P.rM la Ma.lk* Da* ll****th« Dx.akar I IM« 


• Proposals arrive describing scientific objectives. 

• Schedules must be prepared that direct S/C computers to perform 
observations. 

• How can a large set of proposals be transformed into an acceptably 
“good" schedule of S/C functions ? 

• What is an acceptably good schedule ??? 


Coo* Hoar - Tkx Pint la M**tiu Da* ll****.h*i Dai*Mi I IM« 



Constraints. Complications, and Interacting Subsystems 

• Proposed observing time to available observing time ratio - 15:1 

• Instruments have many modes of operation 

• It takes time to slew to targets 

• Targets are routinely occulted by sun. moon. Earth 

• Observing any given target at different times may alter the observa¬ 
tion (length and S/N) 

• Instruments must be wanned up before use 

• All instruments cannot be warm simultaneously (limited power) 

• ST orbits under stationary relay satellites (limited communications) 

• ST must avoid pointing at bright objects (limited sky coverage) 

• ST must keep solar panels pointed at the Sun 

• ... 

kft 41 C«M •«**#▼ - Tin ill Mmiih Q«« KmmiM Btf Ur I i«+4 
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Still More Problems & Constraints... 


Problem Definition 


• Combinatoric explosion of the solution space 

• Can't generate an optimal solution 

• Can't easily generate a metric for "good" solution 

• Even subproblems are hard: Proposal Entry Processing is analogous 
to a PC board construction system whose input is a schematic... 


• Looked to AI for techniques to bound search of solution space 

• Thought it roughly analogous to “pruning" in game playing 

• Found that Planning was an established subfield in AI 


• AI rniMi Cm »•■«* - TIm fmi lu MmW D.« Kmmimi Dhiumi I !*•« 


A* Al Prajcei Cm. S.vAy - TM tint III Maaiha Do Imnui Oki 


Planning in AI 1 

• "Preparing a program of actions to be carried out to achieve goals." 

• "A planner is required to construct a plan that achieves goals without 
consuming excessive resources or violating constraints." 

• "key problems:... 

- must be able to act tentatively [non-deterministicl 

- if details are overwhelming, the planner must be able to focus on 
the most important considerations 

- a planner must operate in the face of an uncertain planning con¬ 
text 

- a planner must attend to interacting subgoals" 


On the Right Track 

• Reassured that my ideas were consistent w/ AI literature 

• Found that there was relevant work reported in the literature 

• "Planning and Meta-Planning" by Mark Stefik (MOLGEN) 

• "Planning in Time: Windows and Durations for Activities and Goals" 
by Steven Vere (DEVISER) 


A» AI Pfffi Cam lw«r - TW Figi fci Mw m>» Dh Mma «—< DhmW. I IM« 

'•••Mu* tmpmn l|«ni. Mataa-Maia lurau Lh*i aa AI Cam *•»*? ■ Tfc. r.m In MaaiAa Oaa RamaiaaI Dniami I IM« 
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MOLGEN: Stefik 


DEVISER: Vere 


• Design of experiments in molecular genetics 

• Developed a hierarchy of abstraction for design tasks 

- Strategy space 

- Design space 

- Laboratory space 

• Dual control, one context for as long as possible, then the other, etc 

• As design is closely related to planning. MOLGEN can serve as a 
model, a good starting point 


. Paper from JPL on scheduling planetary encounters for Voyagers 

• Generates parallel plans to achieve goals with imposed time con¬ 
straints 

• Starts with traditional blocks world planning 

• Adds timing with window construct 

. Refines model for "space world” to include some physical and timing 
constraints 

• Enough in common with ST to be relevant 


Am AI PraiMi Cm. S.mA* - Tto Pw In Mm iM Omm iM.ik.i 


Am Al Pr*,Mi Cam »i»M» Tin Pint Mm a« A. Dam AamaiAai Dkiam< i 1IM 


Approach 


Proposal Transformation 


• Decided on two areas of application of AI: 

• Proposal Transformation 

• Actual schedule construction 


• Appears to be appropriate problem for expert system technology 

• More bounded problem than scheduling 

• There are resident experts 


■ Al PftiMi Cam IiMt - Tin Pint ha Mm a im Dam I . . OmmM I. 


am Al PftiMi Cam tiaAt - Ths Pin. tu MaaiM Daa IamiM D«.am I. INt 
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Scheduling 


Scheduling continued 


. Can t build an expert system w/o an expert . Hybrid approach for exploring problem: 

. Need to understand the problem before attempting to solve it . Scheduling primitives (mechanics) in C 

. -exploratory’ programming: Use AI to probe problem . Existing FORTRAN library for numerical problems 

• Can build different drivers on top of primitives: 

- manual (graphical) 

- C (algorithmic) 

- AI (rule-based) 


>1 Cam Si *4* - 


D««t« 1 ISM 


An AI Pni«i Cam Sw4r - Tlx Pin) Sin Unniki Dm JUmaiAaI OMiattr l. 1M4 


Tools 


• What language ? 

. As the traditional AI language. LISP was first to be considered... 

• Ran up against "LlSPophobia" 


fa, Hiwm TV 

|U> -OH5 

/ 







Prolog 

• Read Clocksin k Mellish text (Programming in Prolog) 

• Was intrigued, but... 

• Seemed too low level for my particular uses (it's real good for express¬ 
ing relationships, for example...) 

• Also, did not find vendors for a VMS Prolog (summer *84) 


Ah Ai Pkimi Cut Italy - Tha f.rat lu Maltha Daa Raaaaikal Dttaatii I 1 N< 


Rule Based Languages 

. In exploring available languages. I came upon 0PS5 and Rosie. 

. Learned that DEC was to offer 0PS5 

• Transformation problem seemed oriented to a production system so¬ 
lution 

. Parts of scheduling system also (constraints and restrictions) 


Ah AI Praiaai Chaa Italy - Tha r.fat la Mhalha Daa Raaaathai Oataaihar I IM4 
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LISP versus 0PS5 


Programmatic Considerations 


Both vendor supported 
LISP 

- more flexible, more powerful, more general, but 

- would have to build the “inference engine" myself 
OPS5 

- much more limited, but 

- alot that I specifically needed is built in 

- call-in. call-out. seemed well supported 


OPS5 is CHEAP ! 

DEC Proven (R1 papers) 

Vendor support seems assured 

Good guess that support environment will be developed by DEC 
they need it themselves. 

Technical: appropriate tool 
Managerial: low risk 


Aa Al Pmj«i Cm. »%a4r • Tta Pim Mwikt Dan HmmiM D«uk« I IM< 
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Tools (continued...) 

• Ordered OPSo soon after Cincinnati DECUS 

• Intent was to use C for lower level mechanical operations 

• FORTRAN tools existed for numerical calculations (no new FOR¬ 
TRAN to be written) 

• MMS for updating segmented rule base (“modular compilation") 

• ??? Test Manager for regression testing of state machine. Does DEC 
use it ??? 


OPSo Support Environment 

• Has an interpretive trace facility built in 

• As goals are essentially states, one builds a monolithic state machine 

• Will DEC Provide support tools?? 

- consistency checker 

- rule editors 

- Meta Rules: presently cannot operate explicitly on Conflict Set.. 


A» Al PraiMt Cam %ta*f - Th* r« ha MmmIm o«• liwnM DaMtar I INI 


A* Al Pr«|Mi Cm* - TW Pim lu MmiA 0»« Im.mK.1 DmaMi I. IMP* 
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Training 


The First Prototypes 


My background—no formal AI but have done hardware and software 
for 15 years and once built a LISP interpreter 
Found reading knowledge of LISP essential-took a refresher course 
Many good reference texts available now. with substantial bibliogra¬ 
phies. 

Read like crazy - excellent way to become fluent in the relevant con¬ 
cepts. 

Handout: an AI bibligraphy from SIGART 
Took a few weeks to sit down and program 


Within week of receipt was writing small OPSo programs 

Towers of Hanoi 

Scientific Instrument Adviser 

Blocks world planner 


Aa AI Pa«(M» Cam tii*A t - Tb* Fim lu M»iM Da. ImhiMI 0.<*«M> I INI 


** Al c **» *••*» - tb* Fim Ik MaaiIm Da* I*h*iui DhiuMi I I Ml 


Towers of Hanoi SI Chooser 

• Good first OPS5 problem • By second week had written this program 

• Only two rules, iterative solution • Excellent testbed for information transfer 

• Most of program was data structures and initialization • Explored three areas 

• No goal (context) switching - control structures within OPSo 

- call out to other languages 

- modular compilation 


• AI Finmi Cam Um4f ■ Tte Fim lu MamAa Daa IammM 


>1 Final Cam S**«i - TAa Pnai hi M 
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SI Chooser, continued 


SI Chooser, continued 


• Wrote first version in one sitting (4 hours) after playing 20 questions 
with an expert 

• Many stubs, but first version could do as much as I could (ie all my 
derived knowledge had been coded into it. 

• Was trivially expandable (an astronomer watching me run it sug¬ 
gested four new rules-iminediately implemented) 

• Incorporated simple-minded explanation facility 

• Recognized -impossible" observations 

• Knew when it was stumped due to incomplete rule set 


• Rewrote about five different ways, exploring different control con¬ 
structs 

• Added C I/O routines for asking questions of users and validating 
answers. 

• Incorporated MMS makefile to recompile either C or OPSo (“modular 
compilation") 


I AI Praia* t Cm* liakr - Tlx Pint la Mas Ik. Dan Imiiui DitiaMf I I Ml 


A* Al Praia*! Com liu«y - Tka Pirn Si* Dan ftaaaaikai D»»Hr I IM« 


Blocks World Planner 

• Needed to prove applicability to planning 

• Block stacker is planning archetype, even reported in JPL Voyager 
planner (in LISP) 

• Using description from that paper, implemented OPSo version in an 
afternoon 

• Incorporates simplication from LISP version 

• Uses only 9 rules 


Acceptance of OPS5 

• Not only was I encouraged, but many non-computer types saw use¬ 
fulness of OPSo for their work 

• Operations Astronomers familiar with constraints, restrictions, and 
good practices 

• Researchers interested in automating recognition of opportunities to 
do parallel science 


r - Tka Pira, Mb M 


Oaiia ka. I INI 


A» Al Praia*i Com li.tr • Tka Pwa* ha Marika 
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Non-AI prototypes 


The Next Six Months 


. Scheduling primitives prototyped in C . Intensive OPSo prototyping 

. Three man-months (conversion from Pascal, plus enhancements) . Prove feasibility for transformation 

. Essential, because of the many things OPSo is not suited for. . Expand transformation capabilities 

. One-half of the preparation period. . j/p OPSo code with database 

• Prototype scheduler driver in OPS5 using MOLGEN control hierar¬ 
chy 

- C lowest ("laboratory**) level 

- OPS5 design level 

- OPSo strategy level 

- Clean work-around for absence of meta-rules 


a *««4v • TW P.m In llNik !>•• Imiiui d„,. h , i 


■ Tb. r«t Ma Maaihe Dee RaMaibai DmmWi I IM< 


Results 

• In 6 months we were able to: 

- identify need for AI techniques 

- learn enough through the literature to be able to plan the next 
steps 

- find, evaluate, acquire, and test tools 

- build necessary conventional system functions 

- learn OPSo and solve several short problems of differing types 

- develop a design model for the AI system parts 

- generate a strategy for system design and implementation which 
includes proving technical feasibility AND reasonable fallback 


a *1 PtaiMi C*m »«•«* - Tto faw la Utaa Dm Ra.iaibai DhmIh I IM4 
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A Bibliography on Knowledge-Based Expert Systems 

in Engineering 1 


D. Sriram 

Design Research Center & 

Civil Engineering and Construction Robotics Laboratories 
Carnegie-Mellon University 
Pittsburgh, PA 15213 

Introduction 

The number of papers published in the applications of knowledge-based expert systems (KBES) to 
engineering problems in the last decade reflects the interest being shown in the engineering 
community. The intent of this report is to provide an annotated bibliography of the applications of 
KBES in engineering. The first four sections deal with applications in Civil (including Architecture and 
Geology), Chemical, Electrical and Computer Engineering, Mechanical. Some papers which are 
common to engineering design, in general, are outlined in Section 5. A number of domain 
independent tools are discussed in Section 6. Section 7 contains a list of books for general reading. 
A list of relevant conferences and journals is provided in Section 8. 

The bibiiography is by no means complete and the author would appreciate pointers to other 
literature in the area for inclusion in a future update. Some of these references are taken from NTIS 
citations from the INSPEC data base; these references contain the word [NTIS]. 


1 Architecture, Civil Engineering, and Geology 

Bennett, J., Creary, L., Engelmore, R. and Melosh, R. 

SAC-ON: A Knowledge-baaed Consultant for Structural Analysis 
Technical Report STAN-CS-78-699, Stanford University, September 1978. 

Bennett, J. and Engelmore R. 

SACON: A Knowledge-based Consultant for Structural Analysis 
In Proceedings Sixth IJCAI, pages 47-49,1979. 

SACON is an expert program that advises a structural engineer in the use of modeling 
options tor MARC, a non-linear structural analysis program. It is implemented in EMYCIN. 
It does not have any interface with the analysis program. 


Bonnet, A., and Dahan, C. 

Oil-Well Data Interpretation Using Expert System and Pattern Recognition 
Techniques 

In Proceedings Eighth IJCAI, pages 185 • 189,1983. 


1 Forthcoming DRC technical report. A number of additions have been made to the bibliogiaphy first published in SIGART 
newsletter, July 34. 
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LITHO, a program for interpreting oil well data is described. The output from the 
program is a litholog, a description of rocks encountered in a well. LITHO is being 
developed at Schlumberger, France. The knowledge-base contains about 500 rules. 


Cobb, J. E. 

A Microcomputer Approach to Contract Management Using At 
Unpublished Master’s Thesis, University of Colorado, Boulder, CO, 1984. 

The knowledge-base and logic for the development of DSCAS. which is intended to 
provide legal advice for construction claims, is developed. Currently DSCAS is designed 
for '’Differing Site Conditions" clause of the U. S. Government standard general 
conditions to a construction contract. 

Cuena, J. 

The Use of Simulation Models and Human Advice to Build an Expert System for 
the Defense and Control of River Floods 
In Proceedings Eigth IJCAI, pages 246-249,1983. 

A conceptual framework for an expert system to aid in the operation of flood control 
and plan civil defense in flood prone areas is provided. The rules are described based on 
a set of mathematical models. System currently pursued by Spanish Ministry of Public 
Works. 

David, H. 

An Analysis of Expert Thinking 

International Journal Man-Machine Studies. Vol. 18, pages 1-47,1983. 

Deals with how human experts acquire, understand and use knowledge in the domain 
of geology, in particular petroleum geology. 

Davis, R. et al 

The Diprneter Advisor: Interpretation of Geologic Signals 
In Proceedings Seventh IJCAI, pages 846-849,1981. 

Paper presents a feasibility study on the use of expert systems for well log analysis. The 
paper published in the eighth IJCAI describes a more recent implementation. 

Duda, R. O., Gaschnig, J. and Hart, P. E. 

Model Design in the Prospector System for Mineral Exploration 

In Michie, D. (editor), Expert Systems in the Micro Electronic Age, pages 153-167, 

University of Edinburgh, Scotland, 1979. 

PROSPECTOR aids the geologist to select mineral deposits. Currently it has more than 
1000 rules in its knowledge-base. 


Eastman, C. M. 

Automated Space Planning 

Artificial Intelligence Vol. 4, No. 1, Spring 1973. 

One of the first papers that addresses the application of heuristics to space planning. 

Fjellheim, R. and Syversen, P. 

An Expert System for SESAM-69 Program Selection 

Computas Report 83-6010, January 1983. (A. S. Computas, P. O. Box, 310, 1322 
HOVIK, Norway) 

Describes an expert system front end for a large finite element program SESAM-69, 
developed by A. S. Computas. Patterned after SACON. Implemented in EMYCIN. 
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Gaschnig, J., Reboh, R. and Reiter, J. 

Development of a Knowledge-Based Expert System lor Water Resource Problems 
Technical Report SRI Project 1619, SRI International, August 1981. 

Describes an intelligent interface (HYDRO) for selecting numerical values of 
parameters that are input to a simulation program (HSPF). 


Gero, J. S. and Coyne, R. 

The Place of Expert Systems in Architecture 

In Proceedings CADD-84, U. K., 1984. 

An introduction to expert systems, along with some prototype applications. 
Implications to synthesis are explored. 

Hammond, P. and Howarth, R. 

A Rule-Based Approach to Geological Knowledge 

Research Report, Imperial College of Science and Technology, U. K., 1984. 

Consists of two knowledge-bases. The first one was directly transferred from 
PROSPECTOR, while second was written by an expert for determining the suitability of 
sites for dam construction. Implemented in PROLOG. 

Hollander, C. R., Iwasaki, Y., Courteille, J-M., Fabre, M. 

The Drilling Advisor 

In Proceedings of Trends and Applications on Automating Intelligent Behavior: 

Applications and Frontiers , pages 21 -27, May 1983. 

Provides diagnosis and therapy for problems encountered by the drilling mechanism 
while drilling. Currently the system has around 250 rules for diagnosing possible problems 
associated with the drill being stuck in the bore hole. It is implemented in KS300, a 
copyrighted version of EMYCIN. 


Ishizuka, M„ Fu, K. S. and Yao, J. T. P. 

Inexact Inference for Rule-based Damage Assessment of Existing Structures 
Technical Report CE-STR-81-5, Purdue University, February 1981 (also see 
Seventh IJCAI proceedings). 

Ishizuka, M., Fu, K. S. and Yao, J. T. P. 

Rule-based Damage Assessment System for Existing Structures 
SM Archives Vol. 8, pages 99-118, Martinus Nijhoff Publishers, The Hague, 1983. 
The above two papers describe SPERIL-I, a rule-based expert system. SPERIL-I 
addresses the issue of damage assessment of structures after earthquakes and other 
possible hazardous events. 


Kruppenbacher, T. A. 

A Microcomputer Approach to Contract Management Using Al 
Unpublished Master’s Thesis, University of Colorado, Boulder, CO, 1983. 

Describes the implementation details of DSCAS. which is implemented in ROSIE. See 
reference by Cobb. 


Lansdown, J. 

Expert Systems: Their Impact on the Construction Industry 
RIBA Conference Fund, U. K., 1982. 

Presents a number of potential applications for KBES in the construction Industry. 
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Lopez, L. A., Elam, S. L., and Christopherson, T. 

SICAD: A Prototype Implementation System for CAD 

In Proceedings of the ASCE Third Conference on Computing in Civil Engineering, 
San Diego, California, pages 84-93, April 1984. 

Describes a framework for the development of a KBES for providing an interface 
between standards governing engineering design and CAD programs. 


MacCallum, K. J. 

Creative Ship Design by Computer 

In Rogers, D. F., Nehrling, B. C. and Kuo, C. (editors), Computer Applications in 
the Automation of Shipyard Operation and Shipyard Design IV, IFIP82, North- 
Holland Publishing Company, 1982. 

MacCallum, K. J. 

A Knowledge-base for Engineering Design Relationships 

In Expert Systems 82, Technical Conference of the BCS SGES, U. K., 1982. 

Deals with the development of a KBES for ship design. Also attempts to incorporate an 
element of learning in the system. 

Manheim, M. L. 

HIERARCHICAL STRUCTURE: A Model of Design and Planning Processes 
MIT Press, Cambridge, Mass., 1966. 

The concept of hierarchical design was first implemented by Manheim for determining 
highway locations. A classical work in the area. 

Markusz, Z. 

Design in Logic 

Computer Aided Design, Vol. 14, No. 6, Pages 335-343, November 1982. 

(other references to this work can be found in Logic Programming Clark, K. L. and 
Tarnlund, S. A. (editors), Academic Press, 1982.) 

Describes the use of logic in architectural design. Implementation language Is 
PROLOG. 

Melosh, R. J., Marcal, P. V. and Berke, L. 

Structural Analysis Consultation using Artificial Intelligence 

In Research in Computerized Structural Analysis and Synthesis, NASA, 

Washington, D. C„ October 1978. 

Illustrates an application of SACON. 

Ohsuga, S. 

A New Method of Model Description • Use of Knowledge Base and Inference 
In Bo, K. and Lillehagen, F. M. (editors), CAD Systems Framework, IFIP83, North- 
Holland Publishing Company, 1983. 

A methodology to represent the model building process in building design is proposed. 
Knowledge is represented in terms of expanded predicate logic and interfaced with a 
relational database. 

Rehak, D. 

Expert Systems in Water Resource Management 

In James, W. and Torno, H. (editors), Proceedings ASCE Conference on Emerging 
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Techniques in Storm Water Flood Management, Niagara on the Lake, Ontario, 
Canada, October 31 • November 4,1983. 

Current systems in water resource management are described. 


Rehak, D. and Lopez, L. A. 

Computer-Aided Engineering : Problems and Prospects 

Civil Engineering System Laboratory Research Series 8, University of lllinios, July 
1981. 

Potential use of KBES for the development of an integrated structural design system is 
addressed. 

Rivlin, J. M., Hsu, M. B. and Marcal, P. V. 

Knowledge-based Consultant for Finite Element Analysis 

Technical Report AFWAL-TR-80-3069, Flight Dynamics Laboratory (FIBRA), 
Wright-Patterson Airforce, May 1980. 

A KBES implemented in FORTRAN and interfaced to the MARC non-linear analysis 
program. 


Radford, A. D., Hung, P. and Gero, J. S. 

New Rules of Thumb from Computer-Aided Structural Design: Acquiring 
Knowledge for Expert Systems 
In Proceedings CADD-84, U. K., 1984. 

Pareto's optimization technique is proposed as an aid to the knowledge-acquisition 
process and illustrated using the floor system design as a paradigm. 


Smith, R. G., and Baker, J. D. 

The Dipmeter Advisor System: A Case Study in Commercial Expert System 
Development 

In Proceedings Eigth IJCAI, pages 122-129,1983. 

The development of Dipmeter Advisor, a KBES for oil-well interpretation, is described. 
Dipmeter Advisor is being developed by Schlumberger-Doll research, Connecticut, U.S.A. 

Sriram, D., Maher, M. L., Bielak, J. and Fenves, S. J. 

Expert Systems for Civil Engineering • A Survey 

Technical Report R-82-137, Department of Civil Engineering, Carnegie-Mellon 
University, June 1982. 

Written as an introduction to KBES for civil engineers. A number of current expert 
systems, KBES building tools and potential applications in structural and geotechnical 
engineering are described. 

Sriram, D., Maher, M. and Fenves, S 

Applications of Expert Systems in Structural Engineering 

In Proceedings Conference on Artificial Intelligence, pages 379-394, Oakland 
University, Rochestor, Ml, April 1983. 

Applications of KBES to various phases of structural design are discussed. 


Stanford, G. 

Potential Applications of Expert Systems in Geotechnical Engineering 
Master’s Thesis, Department of Civil Engineering, Carnegie-Mellon University, 
April, 1983. 
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Potential applications in geotechnical engineering, specifically in the domain of 
Landslide engineering, are addressed. The author also relates his experience-of 
knowledge acquisition from a domain expert and from literature. 

Weiss, S. M. and Kulikowski, C. A. 

Building Expert Programs for Controlling Complex Programs 
In Proceedings 2nd NCAI , pages 322-326,1982. 

A KBES for well log analysis is described. 


2 Chemical Engineering and Material Sciences 

Banares, R. 

Development of a Consultant for Physical Property Predictions 

Master’s Thesis, Department of Chemical Engineering, Carnegie-Mellon 

University, May 1982. 

A KBES for selecting appropriate analytic program that is used to evaluate the physical 
properties of certain chemical substances is described. 

Basden, A. and Kelly, B. A. 

An Application of Expert Systems Techniques in Materials Engineering 
In Proceedings Colloqium on Application of Knowledge-Based Systems, London, 
U. K., 1982 (See also International Jl. of Man-Machine Studies). 

Describes a prototye KBES to predict the risk of stress corrosion cracking. 

Chester, D. L., Lamb, D. E. and Dhurjati, P. 

An Expert System Approach to On-line Alarm Analysis in Power and Process 
Plants 

In Proceedings Computers in Engineering, A. S. M.E., pages 345-351, August 
1984, Las Vegas, Nevada. 

FALCON, currently under development, is a KBES for diagnosing faults in a process 
plant. It comoines both the causal model and the (surface) production rule approach. 
Implementation language is Franz LISP. 


Grimes, L. E., Rychener, M. and Westerberg, A. W. 

The Synthesis and Evolution of Networks of Heat Exchange that Feature the 
Minimum Number of Units 

Chemical Engineering communications, Vol. 14,1982. 

HEATEX aids in the construction of networks that minimize energy requirements by 
allowing the exchange of heat among various process streams. 


Peate, J. 

Building Human Judgement into Computer Programs 
Process Engineering, January 1984. 

A general discussion on the potential applications of KBES in chemical engineering. 

Powers, G. J. 

Non-numerical Problem Sch;rrg Methods in Computer-Aided Design 

In IFIPS Conference on Computer-Aided Design, Eindhoven, The-Netherlands- 

1972. 
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Outlines applications of Al techniques to design. 


3 Electrical and Computer Engineering 

Bellon, C., Robach, C., and Saucuer, G. 

An Intelligent Assistant for Test Program Generation: The SUPERCAT system 
In Proceedings IEEE International Conference on Computer-Aided Design, pages 
32-33, September 1983. 

A conceptual framework for a KBES to assist in generating test programs for complex 
VLSI circuits. 


Basden, A. and Kelly, B. A. 

DART: An Expert System for Computer Fault Analysis 
In Proceedings Seventh IJCAI, pages 843-845,1981. 

DART is designed to provide advice to IBM filed personnel on diagnosis in computer 
installations. Implemented in EMYCIN. 


Bowen, J. A. 

Automated Configuration of Backplane-based Microcomputers 
In Proceedings CADD-84, U. K., 1984. 

A program that automates the design of hardware for a dedicated microprocessor is 
described. 


Brodsky, S. and Tyle, N. 

Knowledge-based Expert Systems for Power Engineering 

In Proceedings of the 15ih Pittsburgh Modeling and Simulation Conference, 

Pittsburgh, April 1984. 

Paper presents a brief review of the development and application of expert systems in 
areas related to electric power engineering. The specific examples discussed include 
nuclear power plant monitoring, power system restoration and hydro-electric plant 
design. In addition, several problems are examined as candidates for future expert 
systems. 

Brown, H., Tong, C., and Foyster, G. 

Palladio: An Exploratory Environment for Circuit Design 

Computer, Vol. 16, No. 12, pages 41-58, December 1983. 

A number of interesting concepts in design are presented. Palladio is an attempt to 
provide an integrated design environment for circuit design. 


Birmingham, W. P. 

MICON: A Knowledge Based Single Board Computer Designer 

Research Report No. CMUCAD-83-21, SRC-CMU Center for Computer-Aided 

Design, December 1983. 

MICON designs a single board computer from hardware requirements. Implemented in 
OPS5. 

Cantone, R. R., Pipitone, F. J., Lander, B., and Marrone, M. P. 

Model-based Probabilistic Reasoning for Electronic Troubleshooting 
In Proceedings Eigth IJCAI, pages 207-211,1983. 

IN-ATE is a KBES for guiding the novice technician through electronic trouble- 
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shooting. It is being developed at the Naval Center for Applied Research, U. S. A. The 
paper discusses a technique to automatically produce a binary decision tree of test points 
to be checked by the technician. 


Chen, S. 

On Intelligent CAD Systems for VLSI Design 

In Proceedings IEEE International Conference on Computer Design: VLSI in 
Computers, pages 405-407, New York, 1983. 

Issues in the applications of KBES to VLSI design are discussed. Distributed KBES are 
proposed for VLSI design. 

[Chip] 

Expert System 

CHIP (Germany), No. 8, pp. 52-4, August 1984 [NTIS]. 

Describes a prototype KBES, being developed on a 16 bit microprocessor, currently 
under development at NIXDORF, a German computer manufacturer. 

Davis, R. 

Diagnosis Via Causal Reasoning: Paths of Interaction and the Locality Principle 
In Proceedings 3rd NCAI, pages 88-94, Washington, D. C., 1983. (See also IEEE 
Computer, October 1983, Int. Journal of Man-Machine Studies, November, 1983 
and Proceedings of 4th NCAI) 

Implementation of a KBES exploiting the causality in electrical circuits is described. 

The concept of locality is used to explain the reason for the difficulty of diagnosing bridge 
faults and for the need for multiple representations. 

de Kleer, J. 

Causal and Tcleogical Reasoning in Circuit Recognition 

Phd Thesis, M. I. T., Al Laboratory , 1979 (also Al MEMO TR • 529). 

Dinbas, M. 

A Knowledge-based Expert System for Automatic Analysis and Synthesis in CAD 
In Proceedings IFIPS Congress, pages 705-710,1980. 

PEACE, a KBES for analysis and syntliesis of electronic circuits, is described. 

Freeman, M., Hirschman, L., McKay, D., Miller, F., and Sidhu, D. 

Logic Programming Applied to Knowledge-based Modeling and Simulation 
In Proceedings Conference on Artificial Intelligence, pages 177-193, Oakland 
University, Rochestor, Ml, April 1983. 

Prolog is used to develop an automated configurer for Burroughs main frame 
computers. 


Fujita, T. and Goto, S. 

A Rule-based Routing System 

In Proceedings IEEE International Conference on Computer Design: VLSI in 
Computers, pages 451 -454, New York, 1983. 

An interactive routing system is described. The designer’s knowledge is represented in 
clause form of first order predicate logic. 


Fusaoka, A., Seki, H. and Takahashi, K. 

Description and Reasoning of VLSI Circuit in Temporal Logic 
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New Generation Computing, Vol. 2, pages 79-80,1984. 

A method for describing and reasoning about the behavior of VLSI circuits withirilhe 
framework of extended temporal logic is described. 


Hartely, R. T. 

CRIB: Computer Fault-Finding Through Knowledge Engineering 

Computer, pages 76-83, March 1984. 

Describes the development of a system for computer fault diagnosis. 

Horstmann, P. W. 

Expert Systems and Logic Programming for CAD 

VLSI Design, pages 37-46, November 1983. 

(see also the paper in 21st Design Automation Conference, pages 144-151) 

Logic programming is applied to solve VLSI design problems in the areas of design for 
testability, functional simulation, fault diagnosis, and automatic test generation. PROLOG 
was used to implement a prototype system for design for testability. 

Genesereth, M. R. 

Diagnosis using Hierarchical Design Models 

In Proceedings 2nd NCAI , pages 278-283, Pittsburgh, 1982. 

The hierarchy inherent in most computer systems is used to develop a KBES. The use 
of this hierarchy helps to reduce the search space. 

Grinberg, M. R. 

A Knowledge-based Design System for Digital Electronics 

In Proceedings 1st NCAI, pages 283-285, Stanford, 1980 (also University of 

Maryland, Phd thesis). 

Semi-Automatic Digital Designer (SADD) uses the idea of structured modular circuit 
design using an interactive user interface. The design is divided into three phases: 1) 
specification acquisition; 2) circuit design; and 3) circuit simulation. 


Kim, J. and McDermott, J. 

TALIB: An 1C Layout Design Assistant 

In Proceedings 3rd NCAI , pages 197-201, Washington, D. C. f 1983. 

TALIB performs automatic circuit layout and interconnections by generating plan steps 
at different levels of abstraction spaces and opportunistically refining each plan at one 
level to more specific steps at the lower level. 


King, J. J. 

Artificial Intelligence Techniques for Device Trouble Shooting 

Technical Report CSL-82-9 (CRC-TR-82-004), Hewlett-Packard Company, August 

1982. 

This report addresses the current state of art of Al in electronic device troubleshooting 
with a comparison with conventional fault analysis. 

King, J. J. 

An Investigation of Expert Systems Technology for Automated Troubleshooting of 
Scientiiic Instrumentation 

Technical Report CSL-82-12 (CRC-TR-82-007), Hewlett-Packard Company, 
August 1982. 
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KBES methodology is applied to troubleshoot a gas chromatograph/mass 
spectrometer, concentrating on a failure mode called radio frequency overdrive. 


Knapp, D., Granacki, J. and Parker, A. 

An Expert Synthesis System 

In Proceedings IEEE International Conference on Computer-Aided Design , pages 

32-33, September 1983. 

Describes the architecture of a KBES for synthesis of VLSI designs. The system has 
four modules: a knowledge-base of design techniques, a data structure representing the 
hardware being designed, a history of the design process, and a man-machine interface. 

Kowalski, T. and Thomas, D. 

The VLSI Design Automation Assistant: Prototype System 

In Proceedings 20th Design Automation Conference, pages 479-483 IEEE-ACM, 

Maiami, 1983. 

The VLSI DAA uses temporarily ordered subtasks to allocate VLSI subsystems. The 
input to the system is an algorithmic dataflow description of a VLSI system and the output 
is a list of technology-independent registers, operators, data paths and control signals. 


Krueger, M. W., Cullingford, R. E. and Bellavance, D. A. 

Control Issues in a Multiprocess Computer-Aided Design System Containing 
Expert Knowledge 

In Proceedings of the IEEE International Conference on Cybernetics and Society, 
pages 139-143, Atlanta • Georgia, 1981 [NTISJ. 

Describes CADHELP, a KBES for the design of digital logic circuits. Scripts are used to 
generate explanation of text and graphic demonstrations. 


Lenat, D. B., Sutherland, W. L., and Gibbons, J. 

Heuristic Search for New Microcircuit Structures: An Application of Artificial 
Intelligence 

The Al Magazine, pages 17-33, Summer 1982. 

The knowledge-acquisition bottleneck in expert system development can be removed if 
the system learns to augment its knowledge base. EURISKO, a system that learns by 
discovery, is applied to the synthesis ol semiconductor devices. 


Maclean, C. and Wilde, P. 

Knowledge-based Electronic Circuit Diagnosis 

In Proceedings Expert Systems 83, Technical Conference of the BCS SGES, 
Cambridge, U. K., December 1983. 

McClelland, E. C., Van Horne, P. R. 

Fast Voltage Prediction Using a Knowledge Based Approach 

IEEE Transactions on Power Apparatus and Systems, Vol. PAS-102, No 2, 

February 1983. 

The system is being implemented in prototype form on the New York Pool real-time 
computer system. 


McDermott, J. 

R1: A Rule-based Configurer of Computer Systems 

Artificial Intelligence, Vol. 19, No. 1. pages 39-88, September 1982. 

R1 configures Vax computer systems. Implemented in OPS, and one of the few KBES 
that is used in industry. 
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Mitchell, T., Steinberg, L., Kedar-cabelli, S., Kelly, V., Shulman, J., and Weinrich, T. 

An Intelligent Aid for Circuit Redesign 

In Proceedings 3rd NCAI, Pages 274-278, Washington, D. C., 1983. 

REDESIGN assists the user in redesigning electrical circuits by focusing on an 
appropriate portion of the circuit, generating and ranking possible changes within the 
circuit. 


Pao, Y. and Ou, S. 

Rule-based Approach to Electrical Power Systems Security Assessment 
In Proceedings of IEEE Conference on Pattern and Image Processing, pages 
340-342,1981. 

Shirley, M. and Davis, R. 

Generating Distinguishing Tests Based on Hierarchical Models and Symptom 
Information 

In Proceedings IEEE International Conference on Computer Design: VLSI in 
Computers, New York, 1983. 

A methodology is developed to diagnose faulty components in digital hardware when a 
list of candidates that are likely to fail is given. A three step process is described. 

Shubin, H. and Ulrich, J. W. 

IDT: An Intelligent Diagnostic Tool 

In Proceedings 2nd NCAI, pages 290-295, Pittsburgh, August 1982. 

IDT was developed to identify faults in PDP 11/03 computers. It helps the technician to 
identify the field replaceable unit to fix the fault. 


Spaanenburg, L. 

Digital 1C Design at Twente University 

In LSIM-83 Proceedings, 1983 University/Government/Industry Microelectronics 
Symposium, pp. 47-51, Twente Univ. of TEchnology, Enschede, Netherlands, 
1983 [NTIS]. 

Experiences and luture enhancements towards a VLSI design assistant are described. 


Smith, M. F., and Bowen, J. A. 

Knowledge and Experience-Based Systems for Analysis and Design of 
Microprocessor Applications Hardware 

Microprocessors and Microsystems, Vol. 16, No. 10., pages 515-519, December 
1982 (see also Jl. Microcomputer Appl., Vol. 6, No. 2, pp 155-161,1983). 

Describes the potentials for KBES for the analysis and design of microprocessor 
applications. Also discusses MAPLE, a prototype system. 


Stallman, R. and Sussman, G. J. 

Forward Reasoning and Dependency-directed Backtracking in a System for 

Computer-Aided Circuit Analysis 

Artificial Intelligence, Vol. 9, pages 195-196,1977. 

ARS, a rule-based language, is used to implement a system for computer-aided circuit 
analysis. Antecedent reasoning is used to deduce facts. The deduced facts have 
associated justifications, which are used by the system in the analysis of failures and to 
reduce the search space. 
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Steinberg, L. and Kelly, V. E. 

The CRITTER System: Analyzing Digital Circuits by Propagating Behaviors and 
Specifications 

In Proceedings 2nd NCAI, pages 284-289, Pittsburgh, August 1982. 

(see also 21 st Design Automation Conference, pages 419-425). 

CRITTER can reason about digital hardware designs through the use of declarative 
representation of the components at different levels of abstraction. It can evaluate the 
correctness and robustness of digital designs. 

Steingberg, L. and Mitchell, T. 

A Knowledge-Based Approach to VLSI CAD: The Redesign System 
In Proceedings ACM IEEE 21st Design Automation Conference, pages 412-418, 
New Mexico, 1984. 

Summarizes the Rutgers AI/VLSI group's work on REDESIGN, an interactive aid for 
functional design of digital circuits. 

Stefik, M., Bobrow, D., Bell, B., Brown, H., Conway, L., and Tong, C. 

The Partitioning of Concerns in Digital System Design 
Technical Report VLSI-81-3, XEROX PARC, CA 94304,1981. 

Discussion on the abstraction hierarchies in digital design. 


Stefik, M. and Conway, L. 

Towards the Principled Engineering of Knowledge 
The Al Magazine, pages 4-16, Summer 1982. 

VLSI domain is used as a paradigm for explaining the structuring of design knowledge. 


Stefik, M. and de Kleer, J. 

Prospects for Expert Systems in CAD 

Computer Design . Vol. 22, No. 5, pages 65-76, April 1583 [NTIS]. 

The importance of KBES lor CAD is emphasized through the paradigm of digital design. 


Sumner, G. C. 

Knowledge-based Systems Maintenance Applications (ATE) 

In Proceedings of IEEE International Automatic Testing Conference, pages 
472-473, Fortworth - Texas, 1982 [NTIS]. 

Describes the usefulness of KBES for electronic maintenance problems. 

Sussman, G. J. 

Electrical Design: A Problem for Artificial Intelligence Research 
In Proceedings Fifth IJCAI, pages 894-900,1977. 

Intelligent recovery in a problem solver for electrical design is described. The 
engineering design process is recast in terms of Problem Solving by Debugging Almost- 
Right Plans. Failures are used to reduce search. 

Sussman, G. J. 

SLICES; At the Boundary between Analysis and Design 
Al Memo 433, M. I. T., iSTT- ’* 

SLICES combines tne notion of equivalence, used by electrical engineers to reduce the 
complexity in a circuit, with identification of parameters. The system uses appropriate 
SLICES along with analysis by propagation of constraints to assign component values to 
a circuit. 


53 



Sussman, G. J. and Steele Jr., G. L. 

CONSTRAINTS • A Language for Expressing Almost-Hierarchical Descriptions 
Artificial Intelligence, Vol. 14, pages 1-39,1980. 

Constraint propagation is used to synthesize and analyze electrical networks. 

Sussman, G. J., Holloway, J. and Knight, T. E. 

Design Aids for Digital Integrated Systems • An Artificial Intelligence Approach 
In Proceedings IEEE International Conference on Circuits and Computers, 
October 1980. 

Taylor, G. S. and Ousterhout, J. K. 

Magics’s Incremental Design-Rule Checker 

In (Proceedings ACM IEEE 21st Design Automation Conference), pages 160-165, 
New Mexico, 1984. 

Although, not strictly an expert system the approach presented here would be useful in 
the development of KBES for design. 

Taylor, J. H., Frederick, D. K., and James, J. R. 

An Expert System Scenario for Computer-Aided Control Engineering 
In Proceedings of the American Control Conference, San Diego, AC, 1984. 

A framework for a KBES in control system design is provided. 


Tong, C. 

A Framework for Circuit Design 

In Proceedings COMPCON84, New York, February 1984. 

Discusses a framework for circuit design that contains design descriptions such as 
components , plans, goals , and tradeoffs. Aiso addresses the issue of control knowledge 
in design. The concepts presented are also relevant in other areas of design. 

Tsukiyama, M. and Fukuda, T. 

An Application of Knowledge Base to Control Systems 

In Proceedings of the IEEE International Conference on Cybernetics and Society, 
pages 342-346. Atlanta - Georgia, 1981 [NTIS]. 

KBES structure is developed as a network organization of modules. These modules 
contain both production rules and calculation tools. 

Vesonder, G. T., Salvatore, J. S., Zielinski, J. E., Miller, F. D., and Copp, D. H. 

ACE: An Expert System for Telephone Cable Maintenance 
In Proceedings Eigth IJCAI, pages 116-121,1983. 

ACE was developed to aid in automated cable maintenance. It takes input from CRAS 
(Cable Repair Administration System) to analyze a large number (in hundreds) of 
telephone cable maintenance reports. It is written in OPS4. 

Williams, T. L., Orgren, P. J., and Smith, C. L. 

Diagnosis of Multiple Faults in a Nationwide Communications Network 
In Proceedings Eigth IJCAI, pages 179-181,1983. 

NDS (Network Diagnostic System) is a KBES for identifying faults in a nationwide 
communications network (COMNET). 


Zippel, R. 


An Expert System for VLSI Design 
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In Proceedings of the IEEE Symposium on Circuits and Systems, pages 191-193, 
Newport Beach, CA, 1983 [NTIS]. 

Discusses the motivation for the development of a KBES for VLSI design. Also provides 
some guidelines for the development of this system. 


4 Mechanical and Industrial Engineering 

Bocquet, J. C. and Tichkiewitch. S. 

An "expert system" for Identification of Mechanical Drawings 
In Ellis, T. M. R., and Semenkov, O. I. (editors), Advances in CAD/CAM, 
PROLAMAT82, Leningrad USSR, May 1982, Published by North-Holland 
Publishing Company, 1983. 

Describes an automatic methodology to transform a given Mechanical drawing into a 
3-D data base. The production rule approach is used. 


Bonissone, P. P. 

DELTA: An Expert System to Troubleshoot Diesel Electrical Locomotives 
In Proceedings ACM, New York City, pages 44-45, October 24-26,1983. 

DELTA is a prototype KBES, implemented in FORTH, developed at General Electric 
Corporate R & D to troubleshoot diesel electric locomotives. It contains about 530 rules. 

Bonissone, P. P. 

Outline of the Design and Implementation of a Diesel Electrical Engine 
Troubleshooting Aid 

In Expert Systems 82, Technical Conference of the BCS SGES, Brunei University, 
U. K, 14-16 September, 1982. 

Brown, D. C. and Chadrasekaran, B. 

An Approach to Expert Systems for Mechanical Design 

In Proceedings of Trends and Applications on Automating Intelligent Behavior: 
Applications and Frontiers, pages 173-180, Sponsored by IEEE and NBS, 1983. 
Three categories of design are identified. The first tv/o categories require innovation 
from the designer, while the third category deals with well-established design alternatives. 

A hierarchy of conceptual specialists is used to solve the problem in a distributed manner. 

An example in the area of mechanical design is presented. It is equally applicable to other 
areas of design. 


de Kleer, J. and Bobrow, D. G. 

Qualitative Reasoning With Higher-order Derivatives 
In Proceedings 4th NCAI, pages 86-91, Austin, Texas. 

Six fundamental laws which govern the time behavior of a physical system or device are 
identified. An application to a pressure regulator is discussed. 


Descotte, Y. and Latombe, J. C. 

GARI: An Expert System for Process Planning 

In Boyse, J. W. and Pickett, M. S. (editors), Solid Modeling by Computers: From 
Theory to Applications, Plenum Press, New York, 1984. 

GARI generates machine planning of mechanical parts. It uses a planner that develops 
a plan by iteratively constraining a loosely specified initial plan. The constraints are drawn 
from a knowledge base provided by experts. 
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Dixon, J. R. and Simmons, M. K. 

Expert Systems for Engineering Design: Standard V-Belt Drive Design as an 
Example of the Design-Evaluate-Redesign Architecture 

In Proceedings Computers in Engineering, A. S. M. E., pages 332-337, August 
1984, Las Vegas, Nevada. 

Describes a framework for experts systems for engineering design. Uses a Blackboard- 
type architecture. The system, called VEXPERT, is exemplified through the design of 
v-belt drives. Implemented in OPS5 and Franz LISP. 


Dixon, J. R. and Simmons, M. K. 

Computers that Design Expert Systems for Mechanical Engineers 
C. I. M. E., pages 10-17, November 1983. 

An overview of potential applications in some areas of mechanical engineering is 
presented. 


FOX, M. S. 

The Intelligent Management System: An Overview 

Technical Report CMU-RI-TR-81-4, Robotics Institute, Carnegie-Mellon University, 

August 1981. 

The Intelligent Management System (IMS) project at C-MU is described. The purpose 
of IMS is to provide managers and planners assistance in day to day tasks. The report 
describes a number of features, such as modelling of organizations, user interfaces, etc., 
of the IMS. 

Fox, M., Lowenfield, S. and Kleinosky, P. 

Techniques for Sensor-Based Diagnosis 

In Proceedings Eighth IJCAI, pages 158-163, August 1983. 

PDS, a forward chaining ruled-based system for implementing KBES for real-time 
diagnosis of machine faults, is described. PDS is implemented over SRL. 


Freed, D. and Wright, D. 

FAXS: An Expert System for the Analysis of Mechanical Failures 

In Proceedings Computers in Engineering, A. S. M. £., pages 338-342, August 

1984, Las Vegas, Nevada. 

FAXS is being developed to aid the engineering student or other people in failure 
analysis and prevention. It uses a MYCIN-type probabilistic scheme to deal with inexact 
inferences. On going research is focused on merging FAXS with CAD and stress analysis 
programs. Implemented in Fortran 77. 

Gini, G., Gini, M. and Morpurgo, R. 

A Knowledge-Based Consultation System for Automatic Maintenance and Repair 
In Ellis, T. M. R., and Semenkov, O. I. (editors), Advances in CAD/CAM, 
PROLAMAT82, Leningrad USSR, May 1982, Published by North-Holland 
Publishing Company, 1983. 

The potentials of KBES for diagnosis and repair of mechanical systems are explored. 


Mamdani, E. H. 

Rule-based Methods for Designing Industrial Process Controllers 
In Proceedings Colloqium on Application of Knowledge-Based Systems, London, 
U. K., 1982. 

Fuzzy techniques are used in the development of a KBES for process control 
applications. Method is currently used commercially for the conti ol of cement kilns. 
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Motoda H., Vamada, N. and Yoshida, K. 

A Knowledge Based System for Plant Diagnosis 

In Proceedings of the International Conference on Fifth Generation Computer 
Systems, Japan, November 7-9,1984. 


McKibbin, M, L. 

Will Al Clash with MIS in the Factory 

Infosystems, Vol. 30, No. 8, pp 99, August, 1983 [NTIS]. 

Potentials for expert systems for planning, scheduling, and other areas of 
manufacturing are discussed. 


Nau, D. S. and Chang, T. 

Prospects for Process Selection Using Artificial Intelligence 
Computers in Industry, Vol. 4, pages 253-263,1983. 

Discusses potential uses of KBES in process planning for manufacturing tasks. 


Nelson, W. R. 

REACTOR: An Expert System for Diagnosis and Treatment of Nuclear Reactor 

Accidents 

In Proceedings 2nd NCAI, pages 296-301, Pittsburgh, August 1982. 

REACTOR is being developed at EG & G, Idaho, for assisting operators in the diagnosis 
and treatment of nuclear reactor accidents. 

Phillips, R. H., Zhou, X-D., Mouleeswaran, C. B. 

An Artificial Intelligence Approach to Integrating CAD and CAM Through 

Generative Process Planning 

In Proceedings Computers in Engineering, A. S. M.E., pages 332-337, August 

1984, Las Vegas, Nevada. 

The PROLPLAN system, a KBES for process planning, and its interface with a CAD 
systems are described. Sample studies from are carried out on a small sample of 
rotational machined parts. A rule-based approach is used. 


Rajagopalan, R. 

Qualitative Modeling in the Trubojet Engine Domain 
In Proceedings 4th NCAI, pages 86-91, Austin, Texas. 

Presents a causal model of a turbojet engine based on the relationship between engine 
parameters. This is used to implement an engine simulation. 


Reddy, Y. V. and Fox, M. S. 

KBS: An Artificial Intelligence Approach to Flexible Simulation 

Technical Report CMU-RI-TR-82-1, Robotics Institute, Carnegie-Mellon University, 

February 1982. 

KBS (Knowledge-Based Simulation) system is a knowledge representation system for 
simulating complex organizations. Features include interactive model creation and 
alteration, simulation monitoring and control, graphics display, and selective 
instrumentation. 


Underwood, W. E. 

A CSA Model-based Nuclear Power Plant Consultant 
In Proceedings 2nd NCAI, pages 302-305, Pittsburgh, August 1982. 
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The Common Sense Algorithm representation is used to model the physical system. 
Diagnostic rules are also represented in this formalism. 


5 General Engineering Applications 

Apte, C. 

Expert Knowledge Management for Multi-level Modelling with an Application to 
Well-Log Analysis 

Technical Report, LCSR, Rutgers University, 1982. 

Deals with the implementation of a KBES incorporating heuristic knowledge and 
algorithmic tools. 

Barbuceanu, M. 

Object-Centered Representation and Reasoning: An Application to Computer- 
Aided Design 

SIGART Newsletter, Vol. 87, pages 33-39, January 1984. 

Discusses the usefulness of using an object-oriented approach to CAD problems. This 
approach provides a powerful framework for building KBES in the areas of design and 
planning. 

Basden, A. 

On Application of Expert Systems 

International Journal of Man-Machine Studies, Vol. 19, pages 461 -477,1983. 

A number of issues on building KBES are addressed. Specific reference is made to 
SCCES, Stress Corrosion-Cracking Expert System. 

Bataii, J. 

Dependency Maintenance in the Design Process 

In Proceedings IEEE International Conference on Computer Design: VLSI in 
Computers, pages 405-407, New York, 1983. 

A case for the maintenance of dependency structures in design is presented, with 
examples from VLSI domain. The concepts presented are equally applicable for other 
domains. 

Bundy, A. 

Intelligent Front Ends 

D. A. I. Research Paper No. 227, Department of Artificial Intelligence, University of 
Edinburgh, England, July 1984. 

Describes the techniques used for developing intelligent front ends for existing 
software, such as finite element analysis programs. 


De Swaan Arons, H. 

Expert Systems in the Simulation Domain 

Mathematics and Computer Simulation (Netherlands), Vol. 25, No. 1, pages 10-16, 
February 1983 [NTIS]. 

Explores the possibilities of the application of KBES to simulation problems. 

Dixon, J. R., Simmons, M. K., and Cohen, P. R. 

An Architecture for Application of Artificial Intelligence to Design 
In Proceedings ACM IEEE 21st Design Automation Conference, pages 634-640. 
(for similar views see papers by Rehak, et. al. in Gero (eds)) 
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The Blackboard model for engineering design is presented. 


Gero, J.(editor) 

Knowledge Engineering in Computer-Aided Design 

IFIP WG-5.2, September 1984, Budapest, Hungary, Published by North-Holland 
Publishing Company. 

Contains a number of recent papers on the application of KBES in engineering. Papers 
encompass Civil, Architecture, Mechanical and Electrical engineering applications. 


Lafue, G. M and Mitchell, T. M. 

Data-base Management Systems and Expert Systems for CAD 
Technical Report No LCSR-TR-28, Rutgers University, 1982. 

The use of database management systems and KBES is discussed with reference to the 
REDESIGN system. 


Latombe, J-C. (editor) 

Artificial Intelligence and Pattern Recognition in Computer Aided Design 
North-Holland Publishing Company, New York, 1978. 

Contains a number of good papers on the application of Al to engineering design 
problems. 

Lowrance, J. D. and Garvey, T. D. 

Evidential Reasoning: An Implementation for Multisensor Integration 
SRI International, Technical Note 307, December 1983. 

The Dempster Shafer theory of evidence is used to develop a system for integrating 
information from multiple sources. 


Maher, M.. L., Sriram, D. and Fenves, S. J. 

Tools and Technniques for Knowledge-based Expert Systems for Engineering 
Design 

Advances in Engineering Software, October 1984. 

Describes the application of OPS5, SRL and PROLOG to engineering design problems. 


McDermott, J. 

Domain Knowledge and the Design Process 

Design Studies Vol. 3, No. 1, pages 31-36, 1982 (also appeared in Proceedings 
18th Design Automation Conference, Nashville, TN, 1981). 

R1 and XSEL are used to illustrate the importance of domain knowledge in the design 
process. 

Preiss, K. 

Data Frame Model for Engineering Design Process 
Design Studies Vol. 1, No. 4, pages 231-243,1980. 

The frame based approach to engineering design is discused. Has many interesting 
concepts. 

Reddy, D. Sriram, Maher, M. L. Tyle, N., Banar", ST, Rychener, M. and Fenves, S.J. 

Knowledge-based Expert Systems for Engineering Applications 

In Proceedings IEEE Conference on Systems, Man and Cyberhetics, India, 

1983-1984. 
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A number of KBES currently under development at C-MU in the areas of Civil, Chemical 
and Electrical Engineering are described. 


Rychener, M. D. 

Expert Systems for Engineering Design: Experiments with Basic Techniques 
In Proceedings of Trends and Applications on Automating Intelligent Behavior: 
Applications and Frontiers, pages 21 -27,1983 (Sponsored by IEEE and NBS). 

The author's experience with the development of expert systems for engineering 
design is discussed. 

Simon, H. A. 

The Sciences of the Artificial 

MIT Press, Cambridge, MA, USA, 1969. 

The chapter on design describes the design process in detail. 

Sleeman, D. and Brown, J. S. (editors) 

Intelligent Tutoring Systems 
Academic Press, London, U. K., 1982. 

Contains a number of articles on expert system approaches to intelligent computer- 
aided instruction. 


Swift, K. and Mathews, A. 

Expert Computers in Engineering Design 
Engineering (UK), Vol. 223, No. 9, pp 673-8,1983 [NTIS]. 

The DACON system for assembly automation and POLYCOAT systems for designing 
coatings are discussed. 


Tokoro, M., Ishikawa, Y., Maruichi, T. and Kawamura, M. 

An Object Oriented Approach to Knowledge Systems 

In Proceedings of the International Conference on Fifth Generation Computer 
Systems, Japan, November 7-9,1984. 

Wade, J. and Shubin, H. 

A Generalized Approach to Diagnostic Problems 
In Expert Systems 82, BCS SGES, England, 1982. 

A general discussion of approaches to building diagnostic expert systems, with an 
emphasis on the advantage of keeping knowledge-base and the inference-mechanism 
separate. 


6 Domain Independent Tools 

The tools described here are available at a modest charge from the developer. A more complete 

description of various tools can be found in the paper by Maher, et. at., described in Section 5. 

Balzer, R., Erman, L., London, P. and Williams, C. 

Hearsay-III: A Domain Independent Framework for Expert Systems 
In Proceedings 1st NCAI, Stanford, 1980. 

Hearsay-Ill is a domain independent version of the Hearsay-ll speech understanding 
system. It is written in AP3, a relational database language embedded in Interlisp. It is 
useful in situations that demand multiple sources of knowledge. Contact Steven Fickas, 
(Fickas@USC-ISI) Oregan State University. 
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Bobrow, D. and Stefik, M. 

The Loops Manual 

Xerox Corporation, 1983 (See Al magazine Vol. 4, No 3., 1983 for a description of 
LOOPS). 

LOOPS is an integration of procedure-oriented, object oriented, access-oriented and 
rule-oriented programming paradigms. It offers a powerful framework for building expert 
systems. Currently it is available only on the XEROX machines that run lnterlisp*D. 
Contact Mark Stefik, Xerox PARC, 3333 Coyote Hill Road, Palo Alto, CA 94304 
(Stefik@XEROX.PARC). 

Clocksin, W. F. and Mellish, C. S. 

Programming in Prolog 
Springer-Verlag, 1981. 

Prolog is a logic-based programming language that is widely used in Europe for 
building KBES. According to the authors,”Prolog is a practical and efficient 
implementation of many aspects of ’intelligent’ program execution, such as non¬ 
determinism, parallelism, and pattern-directed procedure call”. The fifth generation 
computer project started in Japan will use Prolog as the implementation language. For a 
Dec-10 version write to D. Warren at SRI International (Warren@SRI-AI). 


Forgy, C. L. 

0PS5 Users Manual 

Technical Report No: CMU-CS-81-135, Carnegie-Mellon University, August 1981. 

OPS5 is a production system language tor rule-based programming. A number of 
versions of this language exist. The latest version, OPS83, will incorporate a number of 
important features that were not implemented in the earlier version. OPS83 is written in 
the C language. Currently maintained by Charles Forgv, Department cf Computer 
Science, Carnegie-Mellon University, Pittsburgh PA 15213 (Forgy@CMU-CS-A). 


Reboh, Rene' 

Knowledge Engineering Techniques and Tools in the Prospector Environment 
Technical Report 8172, SRI International, June 1981. 

The Knowledge-Acquisition System (KAS) is a combination of powerful inference 
techniques and a system of representing the meaning of concepts that it deals with. 
Knowledge is represented in terms of spaces (a type of frame) and semantic networks. 
Bayesian reasoning is used in the inference mechanism. It ts useful for diagnostic type of 
problems and is implemented in Interlisp. This system was extended (called HYDRO) to 
incorporate numerical calculations. Contact Rene Reboh (currently with Syntelligence), 
SRI International, Palo Alto, Stanford (Reboh@SRI-AI). 


van Melle, W. 

A Domain Independent Production-Rule System for Consultation Programs 
In Proceedings Sixth IJCAI, pages 923-925, August 1979 (see also the EMYCIN 
manual, available from Stanford University Computer Science Department). 

EMYCIN is a domain independent version of MYCIN. It is useful for building diagnosis 
based expert systems. Knowledge is represented in object-attribute tuples. For more 
information write to Department of Computer Science, Stanford University, Stanford, CA 
94305. 


Weiss, S. M. and Kulikowski, C. A. 

EXPERT: A System for Developing Consulation Models 
In Proceedings Sixth IJCAI, pages 942-947,1979. 

It is probably the only KBES tool developed in FORTRAN. It is useful for classification 
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and diagnostic type of problems. It can be interfaced with other existing FORTRAN 
software. Hence, it seems to be a good tool for engineers who wish to interface expert 
systems with engineering software, written in FORTRAN. Contact Shalom Weiss or 
Casimir Kulikowski, Department of Computer Science, Rutgers University, N. J. 
(Weiss® Rutgers). 


Wright, J. M. and Fox, M. 

SRL: Schema Representation Language 

Robotics Institute Technical Report, Carnegie-Mellon University, 1983. 

A frame-based language implemented in Franzlisp. This language is being extented to 
include rule-based programming (PSRL). SRL is maintained by the Intelligent Systems 
Laboratory, Robotics Institute, Carnegie-Mellon University, Pittsburgh, PA 15213 
(Fox@CMU-RI-ISL1). 

Fain, J., Gorlin, D., Hayes-Roth, F., Rosenschein, S. J., Sowizral, H., and Waterman, D. 

The ROSIE Language reference manual 

Technical Report N-1647-ARPA, Rand Corporation, Santa Monica, California 

90406,1981. 

ROSIE is a general purpose programming language, implemented in Interlisp, that 
supports stylized English input to create assertional descriptions. Knowledge is 
represented in the form of facts and rule sets. ROSIE also provides the user a wide range 
of options to express n-ary relations. ROSIE has been successfully used toT)uild a number 
of expert systems, specially for diagnostic and interpretation type of problems. Contact 
Henry Sowizral. 


7 General Reading 

Barr, A. and Feigenbaum, E. (editors) The Handbook of Artificial Intelligence, Vol-I to Vol-ll 
William Kaufmann Inc., Los Altos, California, 1981-1982. 

These volumes will be useful for anyone interested in Al. Volume 1 covers the basic 
topics in Al. Volume II focuses on applications of Al (mostly expert systems), programming 
languages and automatic programming. The final Volume in this series (Volume III) is 
edited by Cohen and Feigenbaum and contains articles on learning, theorem proving, 
models of cognition and theorem proving. 


Dym, C. L. 

Expert Systems: New Approaches to Computer-Aided Engineering 
In Proceedings Twenty-Fifth AIAA-ASME-ASCE-AHS Structures, Structural 
Dynamics and Materials Conference, California, May 15,1984. 

Presents a good overview of expert systems for the engineer. 

Konopasek, M. and Jayaraman, J. 

Expert Systems for Personal Computers - The TKISolver Approach 
BYTE, pages 137-156, May 1984. 

Presents a case for using the TKISolver program as an expert system framework. 

Hayes-Roth, F., Waterman, D. and Lenat, D. (editors) 

Building Expert Systems 
Addison-Wesley Pub:-iiir. a company, 1983. 

It gives a good overview of expert systems. However, it is collection of papers and one 
can see a lot of repetition in the chapters. Further, the book does not have any description 
of logic-based expert systems. 
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Michie, D. 


Expert Systems 

Computer Journal (UK), Vol. 23, No. 4, pages 369-376, November 1980. 

A general review of expert systems is provided, with emphasis on applications. 


Nau, D. S. 

Expert Computer Systems 

Computer, Vol. 16, Pages 63-85, February 1983. 

Gives a good overview of expert systems. 

Rich, E. 

Artificial Intelligence 
McGraw-Hill, 1983. 

Weiss, S. M. and Kulikowski, C. 

A Practical Guide to Designing Expert Systems 
Rowman & Allanheld, pp 194, March 1984 

Addresses a number of practical issues in the building of expert systems. Only 
classification-type problems are covered. 


Winston, P. 

Artificial Intelligence 

Addison-Wesley Publishing Company, 1984. 

Books by Rich and Winston are highly recommended for the novice. 


8 Relevant Journals and Conferences 

Al Journal • Artificial Intelligence Jounal 

Mostly papers on basic research. Quarterly Jounal. 


The Al Magazine * 

Papers are fairly general. Provides interesting reports on research in various 
institutions. Published quarterly. 

Advances in Engineering Software - 

Forthcoming issues may have some articles in the area. Published quarterly from UK. 

BCS SGES - British Computer Society Specialist Group in Expert Systems 

BCS SGES holds a conference every year on applications of expert systems. 

CAD • Computer Aided Design, Published in U. K. 

Papers in this journal deal mostly with work in European countries 

C. I. M. E. - Computers in Mechanical Engineering 

Papers relevant to engineering design are published. Published quarterly. 


Computers and Structures 

Forthcoming issues may have some interesting papers in the area. Published monthly. 
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EXPERT SYTEMS: The International Journal for Knowledge Engineering 

New journal. A number of application articles are scheduled to appear in the coming 
year. Published quarterly 

IEEE - Institute of Electrical and Electronics Engineers 

IEEE holds a number of conferences in this area. The IEEE-ACM DA conferences have 
many interesting papers in the area. 

IFIP - International Federation for Information Processing 

Lots of conferences in the area are held by IFIP. For example, see the call for papers on 
page It, SIGART, October 1983. 

IJCAI - International Conference of Artificial Intelligence 

Held once every two years. Many papers in applied Al are presented. 

NCAI - National Conference on Artificial Intelligence 

A yearly conference on Al. 

SIGART - ACM Special Interest Group in Artificial Intelligence 

A quarterly newsletter which deals with a wide variety of topics in Al. 
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Status of Work Toward Revision of Programing Language Fortran 

by 

Jerrold L. Vagener 
Amoco Production Company 
Tulsa, Oklahoma 

May 1984 

Please direct comments or questions concerning the technical content of 
this report to: Jerrold L. Vagener; Amoco Research Center; PO Box 591; 
Tulsa OK 74012; (918) 660-3978 


**************************** 

The Chairman of Fortran Standards Committee X3J3, Jeanne Adam6, would like to 
call your attention to a series of Fortran Forum meetings to be held in the 
summer and fall 1983. The first two of these one day informational meetings 
have been scheduled for Wednesday, August 8, at E G and G, Idaho Falls; and 
for Monday, August 13, at Colorado St8te University, Fort Collins. More 
detailed announcements of these Forums appear on pages 43 and 45. Additional 
information can also be obtained by calling Jeanne Adams at (303) 491-7596. 
Jeanne would also like to hear from other organizations that would be interes¬ 
ted in acting as host for a Fortran Forum. 

Observers are welcome to attend regular meetings of X3J3. Future meetings of 
the committee are scheduled for 6 to 11 Aug 1984 in Jackson WY; 12 to 16 Nov 
1984 in Fort Lauderdale FL; February 1985 in northern California; and May 1985 
in Champaign-Urbana IL. Because of limitations on meeting space, anyone who 
would like to attend an X3J3 meeting should request further information in 
advance from the X3J3 Vice Chairman, Martin Greenfield, at (617) 671-2912. 
International meetings are also planned for 1 to 5 July 1985 in Germany; and 
8 to 12 July 1985 in England. 

**************************** 
PLEASE COMPLETE THE SURVEY on pages 2, 3, and 4. 
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FORTRAN 6x SURVEY 
FORTRAN STANDARDS COMMITTEE X3J3 
Jeanne Adams, Chair, X3J3 

This questionnaire has been developed to survey the opinions of 
the user community on the new features and the architecture 
proposed by X3J3 for inclusion in the next draft FORTRAN 
standard. The results of this and other surveys and question¬ 
naires will be used by the X3J3 committee in assessing the 
strength of each new facility for inclusion in a draft standard. 
Information about the new features is contained in "FORTRAN 
Information Bulletin", Number 1. Return your questionnaire to: 

Andrew Johnson 

MS 10C17-3 

Prime Computer Inc. 

500 Old Connecticut Path 
Framingham, Ma 01701 

RESPONDENT PROFILE 

Check those that apply. 

Type of Organization: 

Scientific 
Engineering 
Commercial 
Government 
Vendor (Computer) 

University 
Other (state)_ 

Was FORTRAN your first computer language? Yes_ No. 

What is your "language of choice?" _ 

Name the vendor and operating system currently used. 


Are you employed as: 

Professional Programmer 
Problem Solver (Occasional) 
Compiler Writer/Implementor 
Home Computer User 
Manager of Software 
Other 


Do you now use: FORTRAN 66 _ FORTRAN 77_ 77 Subset_ 

Do you subscribe to: FORTEC _ SIGPLAN_ SIGNUM_ 

Have you seen the FORTRAN Information Bulletin summarizing the 
proposals currently under consideration for FORTRAN 8x? Yes_ No. 

List two features for FORTRAN 8X that— 

You want in FORTRAN: You do not want in FORTRAN: 



Name_ Address 


Tel. No. 
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CHECKLIST ON FORTRAN 8x FEATURES 


Array Processing Features. 
WHERE Construct_ 


Data Structures. 


New Source Form (free). 

Significant Blanks_ 

Recursion_ 


Precision Specification. 


Environmental Intrinsics_ 

Loop Constructs_ 

Enhanced CALL_ 


CASE Construct 


Internal Procedures. 
IMPLICIT NONE_ 


Entity Oriented Decl., 

Derived Data Type_ 

MODULES_ 


Event Handling. 


Varying CHARACTER Length_ 

(Note it has been removed 

Bit Data Type (Note that 
it has been removed)_ 


Macros (Note that it 
has been removed) 


Architecture with deprecate 
Features (next page)_ 


General Impression 
Of FORTRAN 6x_ 


Strongly 

Approve 


Approve 


SSSBSS8SSR8SSCI 


Do not 
Approve 


Strongly 

Disapprove 


Dc 

Cat 
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DEPRECATED FEATURES 


Which of these features would you make a candidate for deletion 
in the 199X FORTRAN standard, note FORTRAN 9x. All of these 
features will be retained in 198x. Do you want these removed 
from 199x, retained in 199x or are you undecided? Check one. 


Removed IRetainedt Unde- 
from I in I cided 
199x 199x 

FORTRAN 77 Fixed Position Source From _I_I_ 

Alternate RETURN I_I_ 

Assumed Size Dummy Arrays I_I_ 

Passing Scalar to Dummy Array I_I_ 

Specific Names (not Generic) for Intrinsics_I_I_ 

Statement Functions I_I_ 

BLOCK DATA Program Unit I_I_ 

Arithmetic IF Statement I_I_ 

ASSIGN and Assigned GO TO Statements I_I_ 

COMMON Statement I_I_ 

Computed GO TO Statement I_I_ 

DATA Statement I_I_ 

DIMENSION Statement I_I_ 

DOUBLE PRECISION Data Type I_I_ 

ENTRY Statement I_I_ 

EQUIVALENCE Statement I_I_ 

FORTRAN 77 DO Statement I_I_ 

PAUSE Statement I_I_ 

Please include any comments you wish to make concerning FORTRAN 
8x features and features marked as candidates for deletion from 
FORTRAN 9x on the reverse side of this page. 
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This report describes the current status of the technical work of X3J3 since 
the adoption of X3.9-1978 (Fortran 77). This work, informally referred to as 
"Fortran 8x", is incomplete and tentative, and is subject (and likely) to 
change prior to issuing a draft proposed standard (expected to occur no ear¬ 
lier than 1985). The purpose of this report is to summarize the status of 
current work by X3J3 relative to a future revision of the current Fortran 
standard. A list of criteria for this revision is summarized in section 3.1 
of this document. Comments on any and all aspects of the features described 
in this report are welcomed. 

1. INTRODUCTION 

Among the additions to Fortran 77 contemplated for the next Fortran standard, 
five stand out as the major ones: 

array operations 

improved facilities for numerical computation 
programmer defined data types 

facilities for modular data and procedure definitions 
the concept of "deprecated" features 

A number of other additions are also included in Fortran 8x, such as improved 
source form facilities, more control constructs, recursion, dynamically allo- 
catable arrays of any size, and event handling. 

No Fortran 77 features will be removed; it remains X3J3's intent that any 
standard-conforming Fortran 77 program will be a standard-conforming Fortran 
8x program, and that, with any exceptions clearly listed in the document, new 
Fortran 8x features can be compatibly incorporated into such programs. 


1.1 Array Operations 

Computation involving large arrays is an extremely important part of engi¬ 
neering and scientific uses of computing. Arrays may be used as atomic enti¬ 
ties in Fortran 8x, and operations for processing whole arrays and sub-arrays 
(array sections) are included in the language for two principal reasons: (1) 
these features provide a more consise and higher level language that will 
allow programmers to more quickly and reliably develop and maintain 
scientific/engineering applications; (2) these features can significantly 
facilitate optimization of array operations on all computer architectures. 

The Fortran 77 arithmetic, logical, and character operations and intrinsic 
functions are extended to operate on array-valued operands. These include 


70 



whole, partial, and masked array assignment, arrayvalued constants and 
expressions, facilities to define user-supplied array-valued functions, and 
new intrinsic functions to manipulate arrays, extract general sections, and to 
support extended computational capabilities involving arrays (e.g., array 
reduction). 


1.2 Numerical Computation 

Scientific computation is one of the principal application domains of Fortran, 
and the guiding objective for all of the technical work is to strengthen For¬ 
tran as a vehicle for implementing scientific software. Though nonnumeric 
computations are increasing dramatically in scientific applications (and a 
number of the tentative additions to Fortran reflect that trend), numeric com¬ 
putation remains the workhorse. Accordingly, proposed additions include por¬ 
table control over numeric precision specification, inquiry as to the charac¬ 
teristics of numeric information representation, and improved control of the 
performance of numerical programs. 


1.3 Derived Data Types 

"Derived data type" is the term given to that set of features in Fortran 8x 
that allows the programmer and package writer to define arbitrary data struc¬ 
tures and operations on them. Data structures are user-defined aggregations of 
intrinsic and derived data type fields. Intrinsic operations on structured 
objects include comparison, assignment, input/output, and use as procedure 
arguments. The derived data type facilities may be used, without further oper¬ 
ation definition, as a simple data structuring mechanism. With additional 
operation definitions, derived data types provide an effective implementation 
mechanism for data abstractions. 

Procedure definitions in Fortran 8x may appear internally in a program unit, 
and as such may be used to define operations on derived data types. Internal 
procedures take essentially the same form as external procedures, with addi¬ 
tional provisions for their use as infix operators. New operator symbols may 
be defined, and the intrinsic operator symbols may be overloaded for use with 
new data types. Internal procedures may be used simply as a mechanism for 
defining procedure packages (whether or not new data types are involved), and 
may be used for new operations on objects of intrinsic data types. 
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1.4 Modular Definitions 


There is no way in Fortran 77 to define a global data area in one place and 
have all the program units in an application use that definition. In addi¬ 
tion, the ENTRY statement is awkward and restrictive for implementing a 
related set of procedures, possibly involving common data objects. And 
finally there is no means in Fortran by which procedure definitions, espe¬ 
cially interface information, may be made known locally to a program unit. 

All of these deficiencies, and more, are remedied by a new type of program 
unit that may contain any combination of data element declarations, derived 
data type definitions, procedure definitions, and procedure interface informa¬ 
tion. This program unit, called a MODULE, may be considered to be a generali¬ 
zation of and replacement for the BLOCK DATA program unit. A module may be 
referenced by any program unit, thereby making the module contents available 
to that program unit. This provides vastly improved facilities for defining 
global data areas and procedure packages. It also provides a convenient 
mechanism for encapsulating derived data type definitions (including opera¬ 
tions defined on them), i.e., for encapsulating data abstractions. 


1.5 Deprecated Features 


With the advent of superior facilities, the use of certain older features of 
Fortran should be discouraged, and some of these features should possibly 
eventually be phased out of the language. For example, the numeric facilities 
alluded to above provide the functionality of DOUBLE PRECISION; with the new 
array facilities non-conformable argument association (such as passing an 
array element to a dummy array) is unnecessary (and in fact is not useful as 
an array operation); BLOCK DATA units are obviously redundant and inferior to 
modules. It is the current intent to identify such "superseded" facilities as 
deprecated (according to Webster: "mild or regretful disapproval; lower esti¬ 
mated value") features. Deprecated features will remain part of Fortran 8x; 
it is the intent that complete upward compatibility be maintained between For¬ 
tran 77 and Fortran 8x. Deprecated features may, however, be candidates for 
removal from the version of the Fortran standard following Fortran 8x. It is 
the intent that in this way official notice is given many years prior to 
removing a feature from the standard language. In Section 3.3 below, the pro¬ 
posed deprecated features are identified, together with possible functional 
replacements. 
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2. LANGUAGE SUMMARY 


In this section a summary of proposed Fortran 8x features is given, with 
emphasis upon new features. The description uses a form of BNF slightly modi¬ 
fied from that used in the Fortran 77 standard (X3.9-1978). Metasymbols are 
italicized, and comprise 

Is introduces a syntactic class definition 

or introduces a syntactic class alternative 

/ / encloses an optional item 

/ /... encloses an optionally repeated item 

The principal difference between this form of BNF and that in X3.9-1978 is 
that each definition starts with the name of the syntactic class that is being 
defined; the actual definition follows the metasymbol is or or. In X3.9-1978, 
only the right-hand side appeared, with informal text introducing the class 
being defined. Lower-case words, including hyphenated words, are syntactic 
class names. Upper-case is used for words that actually appear in the Fortran 
code (terminal symbols), even though lower-case is also allowed in the new 
source form. Terminal symbols that may have imbedded blanks (e.g., ENDIF and 
END IF) are shown in only one form. There is no attempt to be completely com¬ 
prehensive in this summary, especially with Fortran 77 features. The syntax 
should be considered illustrative and incomplete; in the interest of brevity, 
some syntactic items (e.g., integer-expr) are not defined, and hopefully are 
adequately clear from context. Both syntax and semantics are subject to 
change prior to issuing a draft standard. 

Each of the following sub-sections has the three part form of (1) a general 
discussion of the particular topic of the sub-section, (2) the BNF descrip¬ 
tions of the features under discussion, and (3) a set of notes and examples 
that provide specific-points of information. Vhere new intrinsic functions are 
listed in the syntax only the function names are given (not the argument 
lists); following the names are brief descriptions of the functionalities. 

2.1 Full Language Overview 

The following highly condensed summary of the full language is provided so 
that one can see at a glance the major components of proposed Fortran 6x. So 
that it is clear which are the proposed new features, these are italicized 
(along with the metasymbols) and placed first (or occasionally last) in a list 
of syntactic class alternatives. Unitalicized items are essentially unchanged 
from Fortran 77, and are not further described in this information bulletin. 
The new features are all described in greater detail in the succeeding sec¬ 
tions . The deprecated Fortran 77 features are last in any list of syntactic 
class alternatives. So that it is clear in this section which features are the 
deprecated ones, ob is used in place of or in these cases. (The italicizing 
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of new features, and the use of ob, occurs only in this section on full 
language overview.) 


program-unit 


unit-heading 


local- 

specification 


declare* 

statement 

attribute 


is unit-heading 

( use’statement ]... 

I local-specification /... 

/ executable-construct /... 

I internal’procedure J... 

END /unit-type /unit-name// 

is MODULE module-name 
or HANDLER handler-name 
or (PROGRAM program-name/ 
or function-heading 
or subroutine-heading 
ob BLOCK DATA identifier 

is type-definition 
or procedure-interface 
or declare-statement 

or REFER refer-name ( attribute /, attribute ]... ) 

or type-declaration 

or IMPLICIT implicit-list 

or PARAMETER ( constant-definition-list ) 

or SAVE / save-list / 

or INTRINSIC procedurc-name-list 

or EXTERNAL procedure-name-list 

or FORMAT ( format-specification ) 

ob COMMON [ /common-block-name// common-list 

ob DATA initial-value-list 

ob DIMENSION dimension-list 

ob EQUIVALENCE equivalence-list 

ob statement-function 

is identifier /,identifier/... : attribute f,attribute/... 


Is non-char-type 
or intent-attribute 
or optional-attribute 
or REFER (refer-name) 
or CHARACTER /(length)/ 
or DIMENSION (dimensions) 
or INITIAL (constant-expr) 
or CONSTANT (constant-expr) 
or SAVE 
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or 

INTRINSIC 


or 

EXTERNAL 

type- 

is 

CHARACTER/*1en/ var-decl/*len ] [ ,var-decl/*len// 

declaration 

or 

non-char-type var-decl /,var-decl/... 

non-char-type 

is 

floating-point-data-type 


or 

TYPE ( type-name ) 


or 

EVENTMARK 


or 

INTEGER 


or 

LOGICAL 


ob 

DOUBLE PRECISION 

var-decl 

is 

identifier /(dimensions)/ 

executable- 

is 

block-case 

construct 

or 

block-do 


or 

block-if 


or 

basic-statement 


ob 

fort ran7 7-do-loop 

basic- 

is 

array-assignment 

statement 

or 

identify-statement 


or 

event-handling-statement 


or 

EXIT [construct-name / 


or 

CYCLE [construct-name] 


or 

assignable-object “ expr 


or 

io-stmt 


or 

GO TO label 


or 

CALL subroutine-name/(/actual-argument-list/)/ 


or 

CONTINUE 


or RETURN /return-code/ 
or STOP /stop-code/ 

or IF (scalar-logical-expr) basic-statement 
ob IF (arithmetic-expr) branch-list 
ob ASSIGN label TO intagar-variabla 
ob GO TO intagar-variabla //,/ (label-list)/ 
ob GO TO (label-list), intagar-variabla 
ob PAUSE /pause-coda) 

assignable- Is [ derived-data-type-object % /... object 

object 

object is array-object 

or scalar-object 

is /unary-operator/ basic-axpr 
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basic-expr is value 

or constant-name 
or assignable-object 
or function-name (/actual-arg-list/) 
or basic-expr binary-operator basic-expr 
or (expr) 


Notes - 

- Statement labels are not indicated in this summary; 
any statement may be labelled. 

- The declare-statement allows "entity-oriented" declarations, 
where the entity name is given first, followed by a list of 
its attributes. This style of declaration complements the 
"attribute-oriented" declaration style of Fortran 77. 

- The ENTRY statement is deprecated and not listed here. 

It is used to partition the local-specifications and 
executable-constructs in a program unit; internal-procedures 
provide equivalent functionality. 

- The MODULE program-unit may not contain a block of 
executable-constructs (except as internal-procedure bodies) 

(see Section 2.5 below). 

- BLOCK DATA program-units may contain only local-specifications. 

- Note the END statement extensions, even though they are not 
italicized. 

- Procedure-headings have minor extensions, even though they 
are not italicized (see Section 2.6 below). 

- Note that, because an assignable-object may be an array or 
array section, expressions and assignments are considerably 
extended, even though they are not italicized (see Section 
2.2 following). 

- Restrictions on ordering of local-specifications are not 
shown here. 

- The EXIT and CYCLE statements may only appear within block-do 
constructs; the RETURN statement may only appear within (internal 
and external) function and subroutine subprograms. 
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The REFER statement associates a refer-name with a collection of 
Attributes. The REFER (refer-name) attribute may be used in 
subsequent attribute lists to represent the collection. 


2. 2 Array Processing 

The proposed array facilities view whole arrays and array sections as atomic 
computational objects from which expressions can be composed and to which 
assignment can be made. That is, a basic aim of array processing is to 
operate where possible directly on the arrays themselves rather than on their 
elements individually. All scalar operations are extended to conformable 
arrays, operating on them in an element-by-element fashion. Both user-written 
and intrinsic functions may* return array values. Operations on whole arrays 
are thus made available in functional form. 

The ability to manage and control storage of arrays has been significantly 
enhanced by addition of the following features: (1) automatic arrays (local 
arrays with variable dimensions) are created on entry to a procedure and des¬ 
troyed on return; (2) allocatable arrays are created by execution of an 
ALLOCATE statement, and are destroyed by execution of a FREE statement or by 
return from the procedure in which they are created; (3) assumed shape arrays 
(dummy arrays) have implicit dimension information passed during a call, 
somewhat analogously to the passing of length information to Fortran 77 
CHARACTER*(*) dummy arguments. 


array-object 

is 

array-name 


or 

array-section /(substring-range)] 

array-section 

is 

array-name (subscript-rangef.subscript-range]...) 

subscript-range 

Is 

integer-expr 

or 

/integer-expr/ :/integer-expr//: integer-expr/ 


or 

one-dim-integer-array-expr 

substring-range 

is 

/integer-expr/:/integer-expr/ 

array- 

constructor 

Is 

[ constructor-value /.constructor-value/... ) 

(note: outer brackets part of- constructor) 

constructor- 

is 

scalar-expr 

value 

or 

integer-expr : integer-expr /: integer-expr/ 


or 

repeat-factor array-constructor 

repeat-factor 

is 

integer-expr 


77 



array-assignment is array-object * array-expr 

or WHERE (array-logical-expr) array-object * array-expr 
or WHERE (array-logical-expr) 

/array-object * array-expr/... 

/OTHERWISE 

/array-object * array-expr/... / 

END WHERE 

or FOR ALL (index-range */,index-range/... /,logical-expr/) 
assignment-statement 

index-range is integer-variable * integer-expr:integer-expr/:integer-expr/ 

identify- is IDENTIFY <range> virtual-array * parent-array 

statement 

range is /lower-bound:/ upper bound /,/lower-bound:/upper-bound/... 

virtual-array is array-name (integer-variable /.integer-variable/.-.) 

parent-array is array-name ( linear-mapping /,linear-mapping/... ) 

array-intrinsic- is arithmetic-logical-reduction-function 

function or inquiry-function 

or construction-function 
or manipulation-function 
or geometric-location-function 
or MATMUL matrix multiplication 

arithmetic- is SUM sum all elements of an array 

logical- or PRODUCT product of all elements 

reduction- or MAXVAL maximum value in an array 

function or MINVAL minimum value in an array 

or COUNT number of true values in an array 

or ANY true if any value in array is true 

or ALL true if all values are true 

or DOTPRODUCT dot product of two arrays 

inquiry- is RANK rank of argument array 

function or EXTENT size of array in each dimension 

or SIZE total number of elements in array 

or LBOUND lower bound in each dimension 

or UBOUND upper bound in each dimension 

construction- is SPREAD replicates array by increasing rank 

function or REPLICATE replicates by increasing extent 

or MERGE merges two arrays, using a mask 
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or 

DIAGONAL 


or 

PACK 


or 

UNPACK 


or 

SHAPE 

manipulation- 

is 

CSHIFT 

function 

or 

EOSHIFT 


or 

TRANSPOSE 

geometric- 

is 

FIRSTLOC 

location- 

or 

LASTLOC 

function 

or 

PROJECT 


creates a diagonal array 

packs array into a vector, with mask 

inverse of PACX 

changes the shape of a given array 

circular shift of argument array 
end-off shift of argument array 
matrix transpose of argument array 

locate first true element 
locate last true element 
select masked values from array 


Notes and Examples - 


- Arrays of zero size are permitted. 

- Two arrays are conformable if they are the same shape (same 
rank and same extent in each dimension). 

- In executing array assignment statements the entire right hand 
side is evaluated before any assignment is made to the target 
array. This is significant when the same array (or sections of 
the same array) appears on both sides of the assignment operator. 

- Element-by-element computation means that the operation takes 
place many times (all logically in parallel), once for each pair 
of corresponding elements of the operands, and the result is an 
array conformable with the operands. For example, 

real A(100), B(100) 

A * A + B*3.0 ♦ sin(B) 

performs A(I) * A(I) + B(I)*3.0 + SIN(B(I)) for all I between 1 
and 100. Arithmetic, logical, and character operators, and scalar 
intrinsic functions operate in this manner. 

- Whole array operations may be masked by FORALL and WHERE 
statements (and WHERE blocks), avoiding computation on certain 
elements and leaving portions of the target array unchanged: 

real A(100,100), 8(100,100), THRESHOLD 
where (B.ne.O) A * A/B ! avoid zero-divide 

where (A.gt.THRESHOLD) A * THRESHOLD I flatten peaks 
forall (1*1:100,>1:100,I.ne.J) A(I,J) • 0.0 I keep diag 
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Array-valued functions are analogous to scalar-valued functions: 


real function CONCAT(A,B) 

real A(:), B(:), CONCAT(size(A)+size(B)) 
CONCAT(1:size(A)) * A 

CONCAT(size(A)+l:) * B 
end function CONCAT 


An array-constructor forms a one-dimensional array from scalar 
values (note that array construction employs square brackets as 
delimiter symbols). This may be "shaped" into multi-dimensional 
arrays with the SHAPE intrinsic function. One use of 
constructors is to create array constants: 


integer A(10) 

A = [1,2,3,4,5,0,0,0,0,0] ! or A « [1:5,5(0]] 

Generally wherever a whole array may be used an array section may 
be used. Examples of array sections of REAL A(8,8), B(10) are: 


8(5:1:-2) 
A(l:7:2,2:8:2) 
A(2:8:2,1:7:2) 
A(1:4,:) 


! elements B(5), B(3), B(l) 

! one color 

! on a checkerboard 

! upper half of A 


Sub-arrays and general sections may be selected and given new 
"virtual array" names by using the IDENTIFY statement: 

real C(l:100,1:100), D(1000) 
identify <1:100> DIAG(I) * C(I,I) 

Since IDENTIFY is an executable statement, the virtual array 
definition can be changed dynamically during execution: 

identify <1:1000> DIAG(I) « D(1001-I) 

Example of the use of assumed-shape arrays: 

function XY2 (A,B) 
real A(:,:), B(-l:,5:) 

In Fortran 77 this would have to be accomplished with something 
like: 

FUNCTION XY2 (A,B,I,J,K,L) 

REAL A(I,J), B(*1:K,5:L) 

The concepts of reduction, construction, manipulation, and 
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geometric-location correctly suggest that the array intrinsic 
functions provide general operations on multidimensional arrays. 
Only the functions MATMUL, TRANSPOSE, and DOTPRODUCT are 
specialized to matrix/vector operations. Following are some 
examples using array intrinsic functions, assuming the 
declarations; 

real X(N), Y(H), T(H,N), E(M,N) 
complex C(N,N) 

Note that some operations may he masked (mask*), dim*l specifies 
operations on columns, and dim*2 specifies operations on rows. 


Ex; 


I €**•* ) % 

iti 


«;»- ( ~ J 


sum(X,mask=X.gt.O.1) 
sum( (X-sum(X)/N)**2) 
maxval(matmul(abs(C),X)/X) 


radii x^ g /fej| of Gershgorin's circles, i*l,N 

X * sum(abs(C),mask*.not.diagonal^true. ,N) ,dim*2) 


chi-squared statistic^* where e.:» 

ti e -i v M 

X * sum(T,dim*l) ! column sums 

Y * sum(T,dim*2) ! row sums 

E * spread(Y,2,N)*spread(X,l,M)/sum(T) ! outer product 

CHI_SQ * sumUT-E)**2/E) 

- Examples of queries without loops or conditional code on: 

real T(M,N) I test scores, M students with N tests 


top score for each student; 
no. scores above average: 
lowest score above average: 
any student all above average? 


maxval(T,dim*2) 

count(T.gt.sum(T)/size(T)) 

minval(T,mask*T.gt.sum(T)/size(T)) 

any(all(T.gt.sum(T)/size(T),dim*2)) 
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2.3 Num e ric Data Type 


These facilities give the programmer portable control over the specification 
of real and complex data objects; they extend the REAL and COMPLEX type state¬ 
ments. The environmental-intrinsic-functions provide information that models 
the processor-supplied numeric system. They provide a portable means for 
adapting numeric algorithms to various arithmetic environments. 


floating-point- is REAL /(float-point-attrf,float-point-attr/)/ 

data-type or COMPLEX /(float-point-attr/,float-point-attr/)J 


float-point-attr 


is /PRECISION10=j attribute-value 
or /EXP_RANGE=/ attribute-value 


attribute-vaiue 


is integer-constant-expr 
or * 


real-constant-char is 

floating-point- is 
inquiry-function or 

environmental- is 

intrinsic-function or 

or 

or 

or 

or 

or 

or 

or 

or 

or 

or 

or 

or 


Notes and Examples - 


R£AL_CHAR /(float-point-attr/,float-point-attr])/ letter 

ACTUAL_PREC (floating-point-argument) 

ACTUAL_£XP_RANGE (floating-point-argument) 


RADIX 

PRECISION 

MINEXP 

MAXEXP 

HUGE 

TINY 

EPSILON 

EXPONENT 

SCALE 

NEAREST 

FRACTION 

SETEXPONENT 

ABSSPACE 

RECSPACE 


model base for numbers 
number of significant digits 
smallest exponent value 
largest exponent value 
largest number of argument type 
smallest positive number 
positive number small relative to 1.0 
exponent value of argument 
scale argument by power of base 
different value nearest to argument 
fractional part of argument 
specify exponent part of argument 
absolute spacing of numbers near argument 
reciprocal of relative spacing 


- The floating point attributes provide specifications for 
minimum numeric properties of the processor-supplied floating 
point system used to implement the relevant data objects. 

- The integer constant expressions in the floating point attributes 
■ay reference the functions ACTUAL_PREC and ACTUAL_EXP_RANGE, 
which return the actual precision and actual exponent range 

for the given datum. 
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In any given floating-point-data-type definition each 
float-point*attr alternative nay appear at most once; if 
the float“point*attr keywords are not used, these attributes 
oust appear in the order listed in the above definition of 
f loat-po int - at t r. 

A type specification with an attribute of, for example, R£AL(10), 
for an entity X is a requirement that X be represented by a 
processor data type that has at least 10 decimal digits of 
precision. The uses of X in expressions, say, determines the 
precision of the arithmetic operations. Such a specification 
provides a portable method of indicating that the algorithm 
requires at least 10 decimal digits of precision. 

The function value ABSSPACE(X) for example can be used to 
terminate an iteration in a portable way by requiring that the 
absolute relative difference between two iterates, X and Y, is 
less than ABSSPACE(X) ~ that is, terminates the iteration when 
abs(X-Y).le.absspace(X): 

do; if (abs(X-Y).le.absspace(X)) exit 

repeat 

A common difficulty with transporting numerical software from 
machine to machine is the difficulty with changes of precision, 
say from single precision on one machine to double precision 
on another. This problem particularly arises for the conversion 
of constants, which are typically spread throughout a program 
and cannot be easily converted when the precision of the data 
types is changed. For instance, consider the constant 1.1 which 
cannot be represented exactly on a binary (or hexadecimal) 
machine. When changing from single precision to double precision 
the constant 1.1 must be rewritten in the program as 1.1D0 in 
order to obtain the double precision value of this datum. Using 
the REAL_CHAR specification to specify an exponent character, 
the precision of all constants that use this exponent character 
can be readily changed. 

Another common problem in writing portable software is the safe 
and accurate range conversion of floating point variables to 
specified forms. For example, to determine the square root of a 
number X, the usual Newton's iteration converges too slowly to be 
a viable algorithm if the initial iterate is too far from the 
square root. Using the intrinsic functions FRACTION and EXPONENT, 
the interval over which the iterates can range can be drastically 
reduced, from which the square root can be efficiently computed. 
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From this result and EXPONENT(X) the square root of X can be 
formed using the SETEXPONENT intrinsic function. Thus, the 
program would look like: 

! Perform the range reduction on X, assuming X is positive. 

IEXP * exponent(X) 

F * fraction(X) 

if (mod(IEXP,2).eq.1) then; IEXP-IEXP+1; F*F/radix(X); endif 

! Now X ■ F*radix(X)**IEXP, IEXP is even, and the square root 
! of F is in the interval (l/rajiix(X)**2,1). Now find SF, the 
! square root of F, and reconstruct the answer from SF and IEXP: 

ANSWER = setexponent(SF,IEXP/2) 


Derived Data Ty 


The structure of a derived data type is a programmer-defined aggregation of 
fields, each field being a data element of primitive type (or another derived 
data type). The aggregation pattern may be fixed or variant (that is, par¬ 
tially dependent on one of the prior fields). A derived data type is defined 
with a TYPE construct; variables of this type may be declared in the normal 
manner. Intrinsic operations on derived data objects are assignment, equality 
comparison, input/output, and use as procedure arguments. These intrinsic 
operations may be augmented with additional programmer-defined operations. 

The structure qualification symbol (for referencing a component of a struc¬ 
tured object) is the percent sign (%). 


type-definition is TYPE type-name 

/field-declaration]... 
/variant-case-block] 
END TYPE /type-name] 


variant-case-block is SELECT CASE (tag-field-name) 

/ CASE case-selector 

/ field-declaration]... ]... 
/ variant-case-block ] 

END SELECT 


field-declaration is type-declaration 

or declare-statement 

component-selection Is structured-object-name • field-name 
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type-constructor 
type-constant 


Is type-noroe (expr/,expr/...) 

is type-name (constant-expr/.constant-expr/...) 


Notes and Examples - 


Functions may return derived data type values. 


The following definition of PLOT_OBJECT defines a data structure 
made up of two fields of type real (the location in two-space), 
one field indicating the nature of the object, and finally the 
object data itself. In this case the object may be either a point 
symbol or a line segment. 


type PLOT OBJECT 
X0,Y0:"real 
CODE: integer 

select case 
case 
case 

end select 
end type PLOT_OBJECT 


! object location 
! type of object 

(CODE) 

(1) ; SYMBOL: character ! point symbol 

(2) ; XI,Yl: real ! line segment 


Let P,Q: type (PLOT_OBJECT) declare two variables P and Q. 
Then the following expressions are examples of valid operations: 


( P*X0 + Q*«X0 ) / 2 
if (PiCODE.eq.Q’.CODE) then 
P = PLOT_OBJECT(0.,0.,1,) 
read *, Q 


! mid-point of P and Q along X 
! compare P and Q CODE fields 
! give P an initial value 
! input value of Q 


2.5 Modules 


Modules are proposed program units for the packaging of data type definitions, 
data object declarations, procedure definitions, and procedure interfaces. 
Modules are not themselves executable. A module that contains only data type 
definitions and data object declarations serves as a global data module. One 
that contains only procedure definitions and interfaces serves as a procedure 
library. One that contains data structure definitions and operations 
(internal procedures) on them serves as a data abstraction mechanism. A 
module may serve as a language extension mechanism by containing new operation 
definitions on intrinsic data types. 
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The use-statement "attaches" the specified module to the using program unit, 
thereby making the public definitions and declarations in the module available 
to the program unit. The use-statement without the module-name is for 
internal procedures specifying access to its host's definitions (note that in 
the absence of a use-statement specifying otherwise, all host definitions are 
automatically available to an internal procedure). 

Through options on the use-statement, a using program may limit its access to 
definitions in the module and may rename the entities it uses. On the other 
hand, the writer of a module has complete control over which module entities 
are public (visible to using programs) and which are private; in the absence 
of explicit, specification to the contrary, the default is public. (The syntax 
for specifying public and private is not shown, nor is the statement for spe¬ 
cifying that the default visibility is private instead of public.) 


use-statement 

is 

or 

USE//module- 
USE//module- 

name/7 ONLY (access/,access/...) 

■name// /ALL/(rename/ ,rename] ...)7 

/EXCEPT(identifier/,identifier/.. 

access 

is 

identifier 



or 

rename 


rename 

is 

identifier ■ 

identifier 

Notes and Examples - 





- An example of the use of modules for defining global data 
pools may be found in Section 3.3.2.4 below. 

- A scheme for using modules to encapsulate procedure libraries 
may be found in Section 3.3.2.5 below. 

- The following is an example of the use of modules as a 
mechanism for encapsulating data abstractions; in this case 
the abstract data type is PLOT_OBJECT, defined above, with 
two defined operations CONNECT and BISECT: 

module PLOT_MODULE 

I insert definition of type PLOT_OBJECT from previous section 

! define an operation to connect two plot_objects with a 
! line segment; CONNECT returns a PLOT_OBJECT value that is 
! a line segment (C0DE*2) connecting two given plot_objects 

internal type(PLOT_OBJECT) function CONNECT(P.Q) operator(//) 


)/i 
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P,Q: type(PLOT_OBJECT) 


CONNECT*;CODE = 2 

CONNECTVYO « PVXO 

CONNECT*.YO * P*.Y0 

CONNECTS 1 = Q\XO 

CONNECTXY1 » Q**YO 

! finished if P is a point symbol, 
! otherwise use tail (XI,Yl) of P 
! as the head (X0,Y0) of CONNECT 

if (P*.CODE .eq. 2) then 
CONNECT%XO * PXX1 
CONNECr.YO * P%Y 1 
end if 

end internal function CONNECT 

! note that two plot_objects, A and B, can be connected 
! using the infi* operator notation A // B 


! define an operation to bisect a line segment, with an "x"; 

! BISECT returns a point symbol PLOT_OBJECT value 

internal type(PLOT OBJECT) function BISECT(P) 

P: type(PLOT_OBJECT) 

BISECT - P ! return P itself if P is not a line segment 
if (P*.C0DE.eq.2) then 
BISECTiCODE = 1 

BISECnSYHBOL = "x" 

bisect^xo * (p* fc xo+PV\i)/2 

BISECTT.YO * (F.Y0+P*.Yn/2 

end if 

end internal function BISECT 
and module PLOT_MODULE 

Any program unit may employ these definitions if it contains 
the statement: 

use /PLOT_MODULE/ 


2.6 Procedures 


Procedures are allowed to be called with keyword actual arguments, called with 
optional arguments, defined with argument intent (e.g., input only), and 
called recursively. A keyword actual‘argument is of the form KEYV0RD= 
actual -argument, where KEYWORD is a dummy-argument-name. This has three advan- 
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tages: (1) if dummy'argument name is wisely chosen, then keywording 

effectively increases readability of the actual'argument'list, (2) keyvorded 
actual-arguments may be placed in any order, which eliminates order errors 
(such as transposing two adjacent arguments) in actual-argument-lists, and (3) 
arguments not needed on a particular call may be omitted. 

Procedure interface information may be provided for any external or dummy 
procedure, including procedures defined by non-Fortran means. This feature 
gives dummy-argument information to calling programs (and for called func¬ 
tions, function type information), which is needed for using keyword and 
optional arguments. It also makes possible validation of actual argument 
types and number. Procedure interfaces, via the INTERFACE block, may appear 
directly in the specifications of calling programs. However, more often inter¬ 
face information will be packaged in modules, which are then USEd by the 
calling program. 

In Fortran 8x, it is proposed that procedure definitions may be made within 
any program unit. Such a procedure is called an "internal procedure" and is 
known only locally within the program unit in which it is defined. The form 
of internal procedures is identical to that of external procedures except for 
the INTERNAL on the heading and END statements. Also, internal procedures 
automatically inherit all host data and procedure definitions, unless such 
inheritance is explicitly suppressed with the use of the USE statement (e.g., 
USE ONLY () suppresses all inheritance from the host). Internal functions 
provide the same functionality as statement functions, but are more flexible 
and not so restricted. A common use of internal subroutines will be as "remote 
code blocks". Internal procedures are called in exactly the same way as 
external procedures. 

An important use of internal functions is to provide operations on derived 
data types. Since infix operators are so common in scientific notation, an 
option is provided with internal functions to allow them to be used as infix 
operators. Similarly an option with internal subroutines allows the assignment 
operator (*) to be used with programmer-defined data conversions. Thus, the 
various features of internal procedures, together with derived data type defi¬ 
nition and module encapsulation facilities, gives Fortran 8x a powerful and 
flexible data abstraction mechanism. 


function-heading 


is [RECURSIVE/ [data-type/ FUNCTION function-name 

(/dummy-argument-list/) /RESULT(identifier)/ 


subroutine-heading 


is /RECURSIVE/ SUBROUTINE subroutine-name 
/(/dummy-argument-1ist/)/ 


procedure-reference 


is function-name (/actual-argument-list/) 
or CALL subroutine-name /(/actual-argument-list/)/ 
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actual-argument-list is positional-argument-list [, keyword-argument list] 

or keyword-arguoent-list 

positional-argument- Is expr [, axpr /... 
list 

keyword-argument- is dummy-argument-name= expr /,dummy-argument-name= expr].. 

list 

optional-attribute /s OPTIONAL 

intent-attribute /s IN 

or OUT 
or IN OUT 

present-intrinsic- is PRESENT (dummy-argument-name) 

function 

procedure-interface is INTERFACE 

/interface-description]... 

END INTERFACE 

interface- is function-heading 

description /local-specification]... 

or subroutine-heading 

/local-specification]... 

internal-procedure is internal-procedure-heading 

/use-statement]... 

[local-specification]... 

[executable-construct]... 

[interna1-procedure]... 

END INTERNAL /unit-type/unit-name]] 

internal- /a INTERNAL function-heading [OPERATOR (operator-symbol)] 

procedure-heading or INTERNAL subroutine-heading [ASSIGNMENT] 

operator-symbol is . identifier . 

or intrinsic-operator-symbol 


Notes and Examples - 

- Arguments are optional, as specified by the OPTIONAL attribute; 
the PRESENT function may be used to determine if a given optional 
argument was actually supplied in the call. 
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No positional arguments may appaar after the first keyword 
argument. 

OPERATOR functions have one or two arguments (the operands of 
the operation); such functions may be called using either the 
functional form or the infix operation form. The intrinsic 
operator symbols (+, *, /, **, //, .AND., .OR., etc.) may 

be overloaded. Alternatively any .name, form may be defined 
as an operator symbol. 

ASSIGNMENT subroutines have two arguments, the first one 
being the left-hand-side of the assignment (the entity being 
defined), and the second being the value to be assigned. The 
usual assignment syntax (with the s sign) may be used in 
assignment procedure calls. 

In the case of both operator and assignment definitions, 
the procedure body defines in detail the intended operations. 

Note that internal procedures may be nested. 

The RESULT identifier may be used with recursive functions to 
remove ambiguity between recursive calls and function value 
assignment (RESULT may also be used with non*recursive 
functions, including OPERATOR definitions). 

The attributes of procedure headings (INTERNAL, RECURSIVE, 
etc.) may appear in any order. 

See the preceding section for examples of internal procedures. 

The following two examples illustrate recursion and the use 
of the PRESENT function: 

recursive integer function ACKERMANN(M,N) result (ACK) 

M,N: integer 

if (M.eq.O) then; ACK * N+l 
elseif (N.eq.O) then; ACK * ACKERMANN(M-l.l) 
else ; ACK * ACKERMANN(M-1,ACKERMANN(M,N-1)) 

end if 

end function ACKERMANN 

real function READNUM (UNIT.FMT) 

UNIT: integer, in, optional 
FMT: character^), in, optional 

LUN,IOS: integer 

LUN * 5; if (present(UNIT)) LUN * UNIT l establish unit no. 


90 



if (present(FMT)) then 

read (LUN,FMT,iostat=IOS) READNUM 
if (IOS.ne.O) READNUM * 0 
else 

read (LUN,*) READNUM 
end if 

end function READNUM 

! X = READNUM () reads from unit 5, list-directed format 

! X = READNUM (10) reads from unit 10, list-directed format 

! X * READNUM (FMT* '(F10.2)’ ) reads unit 5, format F10.2 

- The above two examples are external procedures and, as such, the 
routines calling them do not normally have any interface 
information about them. In Fortran 8x, the use of an interface 
block, which provides calling routines with interface information, 
allows the compiler to check for correctly formed procedure calls. 
The following example is an interface block that contains 
interface information pertaining to the above procedures READNUM 
and ACKERMANN. This interface block may be placed in either the 
calling routine itself, or a module being used by the calling 
routine. 

interface 

recursive integer function ACKERMANN(M,N) 

M,N: integer 

real function READNUM(UNIT,FMT) 

UNIT: integer, in, optional 
FMT: character(*), in, optional 

end interface 


2.7 Program Source Form 


The Fortran 8x source form is completely column-independent, and 
source lines (records) may be any length (a limit of 1320 characters 
per source statement is, however, still the rule). Statements may be 
separated on a line with the "1” (not in a character context) 

initiates a comment (either on a line by itself or following a 
statement), and at the end of a line signifies continuation. 

Blanks are significant characters, and identifiers may not contain 
embedded blanks; conversely, blanks must separate adjacent identifiers 
and keywords. Identifier names may be up to 31 characters long and 
may contain the (underscore) character. Upper and lower case 
may be used interchangeably (except in CHARACTER constants). Either 
apostrophes or quotation marks may be used as character 
constant delimiters. 
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The following is n more formal description of much of the new source 
form. 


source 

is 

/statement ;/... /statement-start/ /comment/ eol 


or 

/statement-continuation/ /comment/ eol 

statement-start 

9 

IS 

statement /;/ 


or 

statement-fragment & 

statement- 

is 

/&/ statement-fragment /; /source// 

continuation 

or 

/&/ statement-fragment & 

comment 

is 

! /character/... 

character- 

is 

' /character/... ' 

constant 

or 

" /character/... " 


Notes - 


- A statement'fragment is a contiguous portion of a statement 
(and may be null). A statement-fragment may end in the midst of 
a (continued) character constant or H, apostrophe or quotation 
mark edit descriptor only if there is no trailing comment. 

- If a statement-fragment (in a statement-continuation) is preceded 

by a any blanks preceding that 'V' are insignificant. 

- The eol stands for the end of a source line of text. 

- If the underscore is used in an identifier it must not be the 
first character of the identifier; 

the underscore is a significant character. 

-If the character used to delimit a character-constant (’ or ") is 
to appear within the constant itself, it must appear exactly 
twice in succession (i.e., " "" " is the same as ' " ' and 
’ ” ' is the same as " ' "). 

- Many of the examples in this document illustrate aspects of 
the Fortran 6x program source form. 
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2.6 Control Constructs 


Two control constructs are added, one for loop control and one for case selec¬ 
tion: 


block-do is DO /(loop-control)/ 

/executable-construct/... 

REPEAT 

loop-control is integer-variable = integer-expr, integer-expr /.integer-expi/ 
or integer-expr TIMES 

block-case is SELECT CASE (enumerable-expr) 

/CASE case-selector 

/executable-construct/... /... 

END SELECT 

case-selector is (value-range /.value-range/...) 
or DEFAULT 


value-range 


is constant-expr 

or /constant-expr/:/constant-expr/ 


Notes - 

- Branches into block constructs are not allowed. 

- The block-do specifies repetitive execution of its block of loop-statements 
until the loop-control (if any) is satisfied, or until an EXIT statement is 
executed. 

- An EXIT statement is allowed only within a block-do (it may be in a block-if 
or block-case that is one of the loop-statements); its execution terminates 
execution of the innermost block-do containing the EXIT statement. 

- Execution of the CYCLE statement causes the next iteration of the loop to 
commence. 

- The indexed form of loop-control is semantically identical to the Fortran 77 
DO statement with an index of type integer. 

- Enumerable-expr is an expression of type integer, character, or logical; 
constant-expr is a constant expression of the same type as enumerable-expr. 

- The case-selectors must be disjoint in any given block-case. 
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* CASE DEFAULT is optional and may not appear more than once in any given 
block-case; if present, it nay appear in any position among the sequence of 
CASE clauses. 

- The block-case causes execution of the block corresponding to the case- 
selector that contains the value of the enumerable-expr; if there is no such 
case-selector then the CASE DEFAULT block is executed; if there is no 
matching case-selector and there is no DEFAULT block, an error exists. 

- Block constructs (if, do, case) may be named by placing an alphanumeric name 
to the right of each of the control statements (e.g., do, repeat, else if, 
etc.). EXIT and CYCLE statements may contain the name of the block-do con¬ 
struct to be exited or cycled. 


2.9 Input/Output 

Input/Output additions include several nev OPEN statement specifiers, name- 
directed I/O, and new edit descriptors. 


position-specifier 

is 

POSITION* position-expr 

action-specifier 

is 

ACTION* action-expr 

delimiter-specifier 

is 

DELIM* delim-expr 

name-directed- 
format-specifier 

is 

/FMT*/ ** 

name-directed-input 

is 

variable-name * data-value [, data-value/... 

slash-edit 

is 

/repeat-count/ / 

engineering-edit 

is 

/repeat-count/ EN width . digits /E exponent/ 


Notes - 

- The position-specifier specifies the position of the file upon open; 
position-expr must evaluate to one of the character values 
'REWIND', 'APPEND', or 'ASIS'. 

- The action-specifier specifies read-only, vrite-only, etc; 
action-expr must evaluate to one of the character values 
'READ', 'WRITE', or 'BOTH'. 
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- The delimiter-specifier is used in conjunction with name-directed I/O; 
delim-expr must evaluate to one of the character values 

'NONE', ’QUOTE’, or 'APOSTROPHE'. 

- The engineering-edit descriptor causes 1-3 digits to be displayed 
to the left of the decimal point such that the exponent is a 
multiple of three. 


2-10 Event Handling 

The event handling mechanism provides a means to transfer control on the occu¬ 
rence of an event to a specified program unit called an event handler. Events 
must be declared, and their monitoring ^:an be selectively switched on and off 
to accommodate the desired level of optimization. 

An eventmark is a data object that registers the occurence of an "event". The 
declaration of an eventmark contains the condition for which the event will 
occur. The value of the eventmark is either .ON. or .OFF. (the constants of 
the data-type EVENTMARK). The scoping and definition rules for eventmarks Are 
the same as for any other data type. 

Event handlers are similar to subroutines, except that they do not have argu¬ 
ments and cannot be called. When an event occurs, the connected handler is 
automatically invoked. Upon completion of a handler, execution may either 
RESUME with the statement following the one in which the event occurred, or 
RETURNUP (return from the procedure in which the handler was invoked). 


event-handling- 
statement 


is ACTIVATE (event-name-list) 
or DEACTIVATE (event-name-list) 
or CONNECT (event-name, handler-name) 
or DISCONNECT (event-name) 
or DISCONNECT (handler-name) 


Notes - 


- The intrinsic operations on eventmarks are assignment and 
test for equality. 

- An optional part of the eventmark declaration (not shown) allows 
the specification of the condition(s) under which the eventmark 
is automatically set on. 
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2.1 _1 _ Oth er Features 

Other added features include IMPLICIT NONE for turning off implicit typing and 
several new CHARACTER intrinsic functions. In addition, restrictions have been 
removed on: assignment from overlapping character positions, zero-lengtk char* 
acter strings, concatenation of CHARACTER dummy arguments, and specifying 
character constants. 


character- 

is 

IACHAR 

same as ICHAR, but based on ASCII 

intrinsic -function 

or 

ACHAR 

same as CHAR, but based on ASCII 


or 

TRIM 

remove trailing blanks from string 


or 

VERIFY 

check for unwanted characters 


or 

ADJUSTL 

circular shift left thru leading blanks 


or 

ADJUSTR 

circular shift right thru trailing blanks 


or 

REPEAT - 

replicate a string of characters 


or 

ISCAN 

first position of any character from set 

implicit-list 

is 

or 

implicit-type [, implicit-type/... 

NONE 

implicit-type 

is 

type ( letter-range /, letter-range/... ) 
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3. LANGUAGE ARCHITECTURE 


The proposed Fortran 8x language contains all of the features of Fortran 77, 
some of which are identified as "deprecated," and additional new features as 
described in Section 2 above. The "core" is that set of language features 
that are not identified as deprecated. "Modules" arc nonexecutable program 
units which contain prepackaged definitions to be used by executable program 
units. 

3.1 The Core 

The core is a complete and consistent language comprising a set of language 
features sufficiently rich for the implementation of most applications. The 
core will have at least the same functional capabilities as Fortran 77. In 
addition, the core should 

(a) be especially suitable for scientific applications, 

(b) be portable, 

(c) be safe to use, and effective for the development of reliable soft¬ 
ware, 

(d) be widely efficiently implementable, 

(e) ' be concise, 

(f) comprise generally accepted contemporary language technology, 

(g) minimize non-automatable conversion from Fortran 77. 

A core-conforming program contains only core features (i.e., does not contain 
any deprecated features). 

3.2 Modules 


Modules provide a mechanism for defining program facilities for subsequent use 
in application programs. Such facilities include global data pools, procedure 
libraries, procedure interface definitions, data abstractions, and language 
extensions in the form of new operators. Modules take the form of MODULE pro¬ 
gram units, and contain data type definitions, data object declarations, 
procedure definitions, and procedure interface definitions. The USE statement 
provides the mechanism for using the public contents of a module in an appli¬ 
cation program. 
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Modules are useful, for example, where the same definitions are needed in a 
number of different program units, because they allow such definitions to be 
■ade only once in a "central" place. This should contribute substantially to 
software reliability and reusability. The use of modules can also contribute 
to execution efficiency through in-line expansion of procedures. Procedure 
libraries may be configured as internal procedures in a nodule and thereby 
made available for in-line expansion in the using program units. 

Modules may be individually standardized, so that standard facility defini¬ 
tions are available to implementors for efficient implementation (e.g., to 
take advantage of specialized hardware). An example might be a module for bit 
data type, which defines the structure of and operations on bit data; stand¬ 
ardizing such definitions allows Implementors to efficiently implement a 
standard bit data facility if they so choose. 

Since a module contains "ready to use" definitions, a standard module provides 
standardized facilities without an added cost burden to a standard-conforming 
Fortran implementation. Therefore, such facilities are part of any Fortran 
implementation, regardless of whether or not the implementor chooses to opti¬ 
mize implementation of them. For this reason, module standardization is an 
extremely powerful and cost-effective mechanism for extending the function¬ 
ality of standard Fortran. 

A standard module must be core-conforming. Operators defined in the module 
must not have the potential to alter the meaning of any core-intrinsic opera¬ 
tion. The module must contain, in the form of appropriate commentary, func¬ 
tional descriptions of all module operations; such functional descriptions 
take precedence over any accompanying procedural implementations of function¬ 
ality. A functional description may be a (set of) mathematical statement(s), 
or take any other form appropriate for comprehensive specification of the 
functionality. In addition, the module must contain a succinct and lucid 
description of the use of the module facilities. 

Initial possibilities for standard modules include 

bit data type 

maximum accuracy arithmetic 

varying-length character (string data type) 

Standard procedure libraries, such as the ISA process control library, the 
Industrial Real Time Fortran (IRTF) library, and the Graphical Kernel System 
(GKS) library are candidates for standard modules. 

Standard modules are separate standards, and are not part of the Fortran 
standard itself. There is a close relationship between standard Fortran and 
standard modules, of course, which gives rise to the concept of a "Fortran 
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family of standards". Any group, Including X3J3, may propose standard modules. 
In addition X3J3 may choose to include certain standard modules in a part of 
the standard Fortran document. 


3.3 Deprecated Features 

As described in Section 1.5, certain features of the proposed Fortran 8x lan¬ 
guage are identified as deprecated and as such are identified as candidates 
for removal from subsequent versions of the Fortran standard. In this sec¬ 
tion, the deprecated features are summarized, together with a discussion of 
possible replacements for needed functionality. 

3.3.1 Summary of Deprecated Features 

1. Fortran 77 source form (e.g., restricted use of columns 1-6) 

2. alternate RETURN 

3. assumed size dummy arrays 

4. passing a scalar (e.g., array element or substring) to a dummy array 

5. specific names for intrinsic functions 

6. statement functions 

7. BLOCK DATA program unit 

8. arithmetic-if statement 

9. ASSIGN statement 

10. assigned-goto statement 

11. COMMON statement 

12. computed-goto statement 

13. DATA statement 

14. DIMENSION statement 

15. DOUBLE PRECISION data type 

16. ENTRY statement 

17. EQUIVALENCE statement 

18. Fortran 77 DO statement 

19. PAUSE statement 

3.3.2 Storage Association 

Storage association is the association of data objects through physical 
storage sequences, rather than by object identification. Storage association 
allows the user to configure regions of physical storage, and to conserve the 
use of storage by dynamically redefining the nature of these storage regions. 
Though the considerable dangers of programmer access to physical storage 
sequences have been well known for a long time, not until Fortran 8x has For¬ 
tran had adequate replacement facilities for certain important functionality 
provided by storage association. Six items in the above list (items 3, 4, 7, 
11, 16, and 17) are due to the identification of storage association as depre¬ 
cated. 
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3.3.2.1 Assumed Size Dummy Arrays 


These are dummy arrays with asterisk as the size of the last dimension. In 
Fortran 8x dummy arrays may also be assumed shape. in which case the extent in 
each dimension is that of the actual argument. Assumed-shape arrays provide 
all of the functionality of assumed-size ones, and more. Assumed-size arrays 
assume that a contiguous block of storage is being passed, whereas with 
assumed-shape arrays an array section not having contiguous physical storage 
(such as a row of a matrix) may be passed also. 

3.3.2.2 Passing a scalar (e.g.. Array Element or Substring) to a Dummy Array 

This functionality is now achieved, and much more safely, by passing the 
desired array section. For example if a one-dimensional array XX is to be 
passed starting with the sixth element, then instead of passing XX(6) to the 
dummy array one would pass the ar^ay section XX(6:). If the eleventh through 
forty-fifth elements are to be passed, the actual argument should be the array 
section XX(11:45). 

3.3.2.3 BLOCK DATA Program Unit 

The principal use of BLOCK DATA subprograms is to initialize COMMON blocks. 

The global data functionality of COMMON is alternatively provided by MODULE 
program units; global data in modules may be initialized at the point of dec¬ 
laration, and thus modules provide a complete replacement option for BLOCK 
DATA subprograms. 

3.3.2.4 COMMON Statement 


The important functionality of the COMMON statement has been its use in pro¬ 
viding global data pools. In Fortran 8x, global data pools nay also be pro¬ 
vided, and more safely and conveniently, with MODULE program units and USE 
statements. Suppose that it is desired to have a global data pool consisting 
of the following: 


INTEGER X(1000) 

REAL Y(100,100) 

COMMON /P00L1/ X,Y 

Each program unit using this global data would need to contain these specifi¬ 
cations. Alternatively, one can define the global data pool in a MODULE pro¬ 
gram unit: 


MODULE P00L1 

INTEGER X(IOOO) 
REAL Y(100,100) 
END MODULE 
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Then each program unit using this global data would contain the statement 

USE /P00L1/ 

This is safer than using COMMON, because the structure of the global data pool 
appears in only one place. In addition the USE statement is very short and 
easy to use. Facilities are provided in the USE statement (but not shown 
here) to rename module objects if different names are desired in the program 
unit using the module objects. 

Modules have another advantage: they do not involve storage association, and 
therefore a module can contain any desired mix of character, non-character, 
and structured objects. Since COMMON involves storage association, a given 
COMMON block cannot contain both character and non-character data objects. 

3.3.2.5 ENTRY Statement 


The ENTRY statement is typically used in situations where there are several 
operations involving the same set of data objects: 

procedure-heading 

local-specifications 
entry1 

RETURN 
entry2 

• • • 

RETURN 

entryn 

RETURN 

END 

The MODULE program unit provides the same functionality: 

MODULE module-name 
loca1-specifications 
INTERNAL procedural 

END INTERNAL 
INTERNAL procedure2 

END INTERNAL 

• • e 

INTERNAL proceduren 
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END INTERNAL 
END MODULE 

A program unit using this module may call each internal procedure in it, 
exactly as if they were entry points. An advantage is that some of the 
internal procedures in a module may be functions and some may be subroutines, 
whereas all of the entry points in a function procedure must be functions and 
in a subroutine must be subroutines. 

3.3.2.6 EQUIVALENCE Statement 

The primary purpose of the EQUIVALENCE statement is to allow the programmer to 
associate, within a program unit, two or more data types with the same storage 
region. There is currently no direct alternative for this functionality in 
the Fortran 8x proposals. 

There were two principal reasons for the EQUIVALENCE statement in early ver¬ 
sions of Fortran. The first is that memory address spaces were typically 
quite small, and equivalencing was needed to reuse the available space for 
different purposes. The second reason is that early versions of Fortran did 
not have a rich set of data types and structures and transfer functions 
between tvpes, so that equivalencing was useful in simulating certain data 
types strictures. Both of these reasons have now largely disappeared. 

Much of the same practical effect of reusing physical storage can, in fact, be 
achieved with the proposed facilities without using the EQUIVALENCE statement. 
Dynamic local arrays may be of any size, controlled by procedure arguments. 
Since dynamic arrays "disappear" upon return from the procedure, other proce¬ 
dures may use this space for other dynamic arrays of different shapes, sizes, 
and types. Similarly, allocatable arrays disappear when they are freed expli¬ 
citly and on return from the procedures in which they were allocated. The 
IDENTIFY statement allows part of an array to be referred to as a completely 
different object (but of the same type). 

3.3.3 Redundant Functiona1ity 

A number of features are identified as deprecated simply because they are now 
completely redundant, having been superseded by superior language features. 
These redundant features are items 1, 5, 6, 8, 12, 13, 14, 15, and 18 in the 
list above. 

Tortran 77 source form -- replaced by the new source form 

(Section 2.7 above) 

specific names for Intrinsic functions -- use generic names 
statement functions -- replaced by internal functions 
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arithmetic*if statement 
computed-goto statement 


DATA statement 


DIMENSION statement 


(see 3.3.3.1. below) 

-- replaced by logical-if and block-if 

•” replaced by block-case construct 
(see 3.3.3.2 below) 

-- replaced by INITIAL attribute 
(Section 2.1), and by assignment 
of array constants (Section 2.2) 

-* use type declarations instead 


DOUBLE PRECISION statement -- use precision control attributes 

(Section 2.3) 


Fortran 77 DO statement -- replaced by block-do construct 

(Section 2.S) 


3.3.3.1 Use of Internal Functions for Statement Functions 


The statement function definition 

function-name(dummy-argument-list) * expr 

may be completely replaced by the internal function definition: 

INTERNAL FUNCTION function-name(dummy-argument-list) 

type-specif ication-of-dummy-arguments 
function-name * expr 

END INTERNAL 

The use of the internal function in the executable code is the same as the use 
of the statement function. 

3.3.3.2 Example Replacement of the computed-aoto Statement 
The code sequence controlled by the computed-goto: 
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GOTO (labell, label2, 


• • • I 


labeln), integer-variable 


GOTO labelz 
labell CONTINUE 
• • • 

GOTO labelz 
label2 CONTINUE 


• • • 

GOTO labelz 

• • • 

labeln CONTINUE 
GOTO labelz 
labelz CONTINUE 

may be replaced by the block-case construct: 

SELECT CASE (integer-variable) 

CASE DEFAULT 
• • # 

CASE (1) 

• It 

CASE (2) 

• • • 

• • • 

CASE (n) 

• • • 

END SELECT 

3.3.4 Other Deprecated Features 

The remaining obsolete features (items 2, 9, 10, and 19) in the above list are 
neither related to storage association nor directly replaced by superior fea¬ 
tures. They are all in some sense "bad practice" in terms of generally 
accepted software principles, however, and their effects may be achieved in 
ways that are generally now considered better software practice. 

3.3.4.1 Alternate RETURN 


Alternate returns introduce control (branch point) information into argument 
lists, and then one (the called) program unit can directly control execution 
sequence in another (the calling) program unit. This tends to complicate the 
readability and maintainability of software using this feature. Better prac¬ 
tice, in terms of readability and maintainability, is to use a data element in 
the argument list to contain a "return code", which can then be used in the 
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calling program to explicitly control the execution sequence in the calling 
program. For example, consider the following use of alternate returns: 

CALL subr-name(X,Y,Z,*100,*200,*300,...) 

GO TO 999 
100 CONTINUE 

GOTO 999 
200 CONTINUE 

GOTO 999 

999 CONTINUE 

where labels 100, 200, 300, etc., are the beginnings of the code blocks to be 
selected from upon return. In many cases, the effect can be more safely 
achieved with a return code and a block-case structure: 

CALI, subr -name (X, Y, Z, R£TURN_C0DE ) 

SELECT CASE (RETURN_CODE) 

CASE ('conditionl') 

CASE ('condition2') 

END SELECT 

Alternatively, RETURN_CODE could be used to explicitly control direct branches 
(GOTOs) to the desired branch points. Maintainability is enhanced with the 
use of RETURN_C0DE because a new selection case can be added in a convenient, 
straightforward manner, without modifying the actual and dummy argument lists. 

3.3.4.2 ASSIGN and assixned-goto 

The ASSIGN statement allows a label to be dynamically assigned to an^ integer 
variable, and the assigned-goto statement allows "indirect branching" through 
this variable. The dangers of such dynamic indirection, especially when mixed 
with integer arithmetic operations, have long been recognised, and a compre¬ 
hensive alternative to this functionality is not provided. An important prac¬ 
tical use of such indirect branching, however, is to return from simulated 
internal subroutines. Consider the following example code, which calls" one 
of several "internal subroutines" in the program unit: 

ASSIGN 120 TO RETURN ! sat up return point ^ 

GOTO 740 1 branch to "subroutine 

120 CONTINUE 
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740 CONTINUE 


! "subroutine" body 


GOTO RETURN 


This functionality is provided in a much better way, through the use of 
internal subroutines: 

CALL subroutine-name 
• • • 

INTERNAL SUBROUTINE subroutine-name 
... ! subroutine body 

END INTERNAL 


This illustrates the use of internal subroutines to conveniently provide 
"remote code block" functionality. 

3.3.4.3 PAUSE Statement 


Execution of a PAUSE statement requires operator/system-specific intervention 
to resume execution. In most (if not all) cases, the same functionality can be 
achieved as effectively and in a more portable way with the use of appropriate 
READ statements. 


end of Fortran Information Bulletin 
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DIGITAL RESPONSE TO FIB-1 


Digital Comments on the Progress of X3J3 


Although Digital Equipment is in favor of the publication of For¬ 
tran Information ftjlletin 1, we believe that certain changes must 
De made before it is published, we, therefore, vote NO until the 
following issues are resolved. 

1. We are very concerned about compatibility with existing For- 
tran programs. Although the coverletter says "Programs currently 
standard-conforming will not become non-standard-conforming.", we 

f re -.u f °^« d to wonder "h* 1 this means in the light of statements 
in the FIB itself such as: 

"minimize non-automatic conversion from Fortran 77" section 
3. 1, page 29 


O 

^1 


"Blanks are significant characters, and identifiers may not 
contain embedded blanks", section 2.7, page 23 


Can a Fortran-77 program be modified so that some of its state¬ 
ments use new features, such as the new source format or the new 
declarations? What restrictions are there, if any, on the use of 
newly defined features, such as array arithmetic, on variables 
that appear in COMMON or EQUIVALENCE statements? 


Digital would like to see an explicit compatibility 
somewhere near the beginning of the FIB. 


statement 


2. While we believe that there is a definite requirement for the 
array and data structure language extensions, we are not certain 
that many of the other features are worth the performance degra¬ 
dation and delay in appearance of the next standard that they 
will cause, we would like to see the sentence "The committee wel¬ 
comes comments", in the preamble, expanded to solicit comments on 
the need for the various features described. 


Sincerely, 


Lois C. Frampton 

X3 Principal 


In her cover letter to the Fortran Information Bulletin, Jeanne 
Adams, Chair of X3J3, solicited comments from X3 on the committee 
process. 

Although DEC voted against publishing the current FORTRAN Infor¬ 
mation Bulletin, we are strongly in favor of publishing a modi¬ 
fied version of the FIB which clarifies the issues we spelled out 
in our NO ballot. The reason we favor publication of such a do¬ 
cument is that we believe that the FORTRAN standardization effort 
is seriously off-course and needs to be subjected to considerable 
scrutiny by the general FORTRAN user community. The following 
comments outline DEC'S concerns about the contents of the FIB, as 
opposed to its publishability. They are not by any means exhaus¬ 
tive inasmuch as the FIB itself is not a complete language 
description, but they point out several general areas of concern. 

1 THE FIB DESCRIBES A NEW LANGUAGE, FORTRAN IN NAME ONLY 

The FIB describes a totally new language, completely unlike any 
existing FORTRAN implementation, even those which have numerous 
extensions to the FORTRAN 77 standard. The language shows the 
symptoms of design by committee. It randomly incorporates 
features from a variety of other languages, arbitrarily defines 
"modern" language features to replace "obsolete" features, and 
almost as an afterthought tacks on FORTRAN 77, the existing stan¬ 
dard. The result is a language that is large, complex, hard-to- 
implement, hard-to-understand , inconsistent, and not demonstrably 
compatible with the current standard. 

2 STANDARDIZATION OF IMPORTANT FEATURES IS BEING DELAYED 

One immediate problem with this sort of language design is that 
it significantly delays the standardization process. Features 
for which there is a crying need are not being standardized 
quickly enough because of the attempt to convert FORTRAN to a 
modern programming language. 

Two areas where standardization is needed immediately are array 
features and data structures. There already exist a variety of 
FCRTRANs with array extensions, FORTRAN preprocessors for array 
features, and new FORTRAN-based languages with array features. 
The more standardization is delayed, the more non-portable solu¬ 
tions appear. 

Heterogenous data structures are always high on the list of 
features which FORTRAN users would like to see in the language, 
and, as with array features, there are numerous non-portable ex¬ 
tensions. 

Alone, these two features are hard enough to standardize. In 
combination with hundreds of other new features and redesign of 
existing features, they have been and will be delayed for years. 



3 THE LANGUAGE IN THE FIB IS NOT WHAT FORTRAN USERS HAVE ASKED 
FOR 

The language described in the FIB contains some features that in¬ 
corporate advances in programming language design in the decades 
since FORTRAN first appeared, but which are not heavily requested 
by actual FORTRAN users, at least not by DEC FORTRAN users or 
FORTRAN users in published surveys. Features such as entity- 
oriented declarations (section 2.1 p 6-8), looping constructs to 
replace the DO loop (section 2.8, p. 24-25), new source form 
(section 2.7, p. 23-24), and significant blanks (section 2.7, p. 
23) may be desirable in a language designed from scratch, but 
they will not supplant existing usage. They simply clutter up 
the language and make it harder to describe. 

Other features may be desirable in the long run, but are still 
much too experimental to be standardized in a language as old as 
FORTRAN. An example is the whole data abstraction facility with 
derived data types (section 2.4, p. 15-17), user defined opera¬ 
tors (section 2.6, p. 20-21), and information hiding in modules 
(section 2.5, p. 17-18). We do not even know yet that such 
features will work well in a language such as Ada(TM) where they 
are a fundamental part of the language design, much less in FOR¬ 
TRAN where they are being jammed into an existing language. 

4 ATTEMPTS TO MODERNIZE FORTRAN ARE MISGUIDED AND LIKELY TO FAIL 

The FIB attempts to modernize FORTRAN by declaring certain 
— L features obsolete, by defining replacements for the obsolete 
O features, and by adding a host of altogether new language con- 
00 structs. The hope is that programs will cease using the obsolete 
features and that the features can be dropped from succeeding 
FORTRAN standards. In theory, this staged approach to moderniza¬ 
tion is appealing, and might even be feasible for a few features 
(the assigned GOTO comes to mind), However, any implementor knows 
that it is virtually impossible to drop any feature from an im¬ 
plementation, no matter how obscure, as long as there are any ex¬ 
isting programs which depend on it. 

The FIB proposes that a large number of long-established FORTRAN 
features be deprecated (section 3»3), including some of its most 
characteristic constructs such as COMMON, EQUIVALENCE, the exist¬ 
ing syntax for DO loops, and FORTRAN 77 source form. It is in¬ 
conceivable that these features could ever be dropped from the 
FORTRAN language, so that it is really a hollow effort to depre¬ 
cate them. It is not the purpose of a language standard to be a 
guide to programming style. 

5 THE NEW LANGUAGE IS NOT WELL-INTEGRATED WITH FORTRAN 77 

Many of the new features described in the FIB, while not strictly 
incompatible with FORTRAN-77, are not well integrated with it. 
The FIB does not discuss semantics in any detail , but there are a 
number of obvious problems. What are the rules for mixing old 
and new source form? What are the rules for mixing new storage 
independant features such as general precision and data struc¬ 


tures with old storage dependant features such as COMMON and 
EQUIVALENCE? What are the rules for mixing attribute and entity 
oriented declarations? What are the rules for mixing features 
which imply static storage such as SAVE and DATA with features 
which imply automatic storage such as recursion and automatic ar¬ 
rays? The FIB concentrates on the advantages of the new features 
and pays lip service to compatibility, but for the most part ig¬ 
nores the mechanics of this difficult issue. 

6 THE NEW LANGUAGE WILL BE DIFFICULT TO IMPLEMENT 

The FIB describes a language which is considerably more difficult 
to implement than FORTRAN 77. Recursion (section 2.6), automatic 
arrays (section 2.2), and arrays that can be allocated and freed 
(section 2.2) assume the availability of non-static storage. As 
described in the previous paragraph, there are many new features 
which interact in curious ways with existing features and make 
parsing difficult. User defined operators (section 2.6) and 
overloaded functions (section 2.6) greatly increase the complexi¬ 
ty of expression parsing. Modules (section 2.5) imply a compila¬ 
tion library or equivalent compilation mechanism. 

The consequence of the increased difficulty of implementation is 
that it will be even longer between the appearance of a new stan¬ 
dard and the appearance of compilers than it was for FORTRAN 77, 
the compilers will be slower and larger, the compilers will be 
less reliable and harder to validate, and there will be more con¬ 
flicting interpretations. 

7 THE NEW LANGUAGE IS INEFFICIENT TO IMPLEMENT 

The FIB also contains many features that are very difficult to 
compile into efficient code. Since FORTRAN has a long tradition 
of high quality optimizing compilers, and FORTRAN users expect 
FORTRAN programs to run efficiently, this is a matter of serious 
concern. It seems that goals such as language elegance and ex- 
presiveness have taken precedence over implementation efficiency. 
The new features require much more interpretive code than FORTRAN 
77 and in some cases require less efficient code to be generated 
for existing language features. 

Array features (section 2.2) are a primary example of the effi¬ 
ciency problem. Since there is no storage association defined 
for arrays in the language and no language features which would 
allow a compiler to distinguish between old arrays with storage 
association and new arrays without it, a compiler is forced to 
generate interpretive code for all dummy arrays. The compiler 
has to pass array addressing information in the calling program, 
extract It in the called program, and cannot take advantage of 
optimizations which depend on storage association. The Important 
point is that this applies to all array arguments, not Jmat those 
which actually use new features. 

The current level of performance on existing programs could be 
obtained by dependent compilation or by parallel architectures 
where storage association is less important, but performance 



would suffer on most current architectures with most current com¬ 
pilation techniques. 

Related to the above problem is the fact that the new array 
features will force many implementations to use new calling 
mechanisms to pass array arguments. As a result, existing li¬ 
braries may not be able to be called by programs compiled with a 
new compiler unless the libraries themselves are recompiled. The 
problem is similar to the problem that occurred with FORTRAN 77 
in passing character constants as arguments to existing li¬ 
braries, except that it will be much more pervasive. 

Another implementation problem area is the numeric data type 
(section 2.3) • The numeric data type allows the programmer to 
define the minimum range and precision for a floating point data 
type; a compiler can map the data type to an appropriate hardware 
type. The language described in the FIB allows a dummy argument 
to assume the numeric attributes of the actual argument passed to 
it. This may require a compiler to generate either multiple code 
sequences or interpretive code to handle all possible combina¬ 
tions of data types and arguments. 

8 THE NEW LANGUAGE ENCOURAGES PARTIAL IMPLEMENTATIONS 

The primary purpose of language standardization is to make it 
possible to write programs which are portable from one machine to 
another. The size and complexity of the language described in 
the FIB will encourage just the opposite. There are likely to be 
numerous subset implementations which simply extend FORTRAN 77 
with just those features which FORTRAN users have been demanding 
and simplify or ignore the remaining features. We would expect a 
situation similar to X3.53-1976, PL/I. There are no known full 
implementations of that standard. 


IBM COMMENTS 
re 

Approval for Public Release 
FORTRAN Information Bulletin (FIB-1) 

We wish to thank the X3J3 committee for its extended and en¬ 
thusiastic work thus far. Many useful proposals have been made 
for the FORTRAN language. 

To the question: "Do you agree that the document attached to 
X3/8*4-113, should be released as FORTRAN Information Bul¬ 
letin-)?", the IBM vote is "NO". 

Significant characteristics of the FORTRAN language and X3.9 
standard, as described in the April 1978 SD-3 "Proposal for Con¬ 
tinuation of the X3 Standards Project on FORTRAN" are (SD-3 sec¬ 
tion numbers are shown): 

3.2 Interchange 

"The standard provides for a degree of portability of both 
programs and programmers between different computers..." 

3.3 Educational 

"The standard provides a language definition that can be 
used by both authors... and teachers... textbooks, reference 
manuals, and other documents will become more consistent... 

# n 

3.*1 Economics 

"Interchangeability of programs and programmers has proven 
to be of major economic advantage within the industry. The 
continued maintenance and revision of the standards protects 
the investment in already existing FORTRAN programs and FOR¬ 
TRAN language processors" 

*4. 1 State of the ART 

"During development of a new revision to X3.9, it is likely 
that augmentations will mainly be drawn from functionality 
that exists in advanced implementations of existing proces¬ 
sors" . 

5.2 User Operational Considerations 

"Once a language standard is in force and there are conform¬ 
ing programs, incompatible change, even a small change, im¬ 
pacts the user community." 

5.3 Cost Considerations 

"One of FORTRAN'S most important characteristics is that ef¬ 
ficient processors can be implemented at reasonable cost." 



This "NO" vote is based on the following observations: 

1. That the current direction of the X3J3 committee, in 
redesigning FORTRAN by a combination of new featurs and 
deprecations, does not preserve the portability, consisten¬ 
cy, and interchangeability characteristics described in the 
SD-3. The redesign described in the document has a signifi¬ 
cant negative impact on all existing programs, texts, and 
users. 

Should such a redesign (or new language) be desirable, it should 
be initiated by a new SD-3, either for X3J3 or some other X3 com¬ 
mittee . 


2. That the large amount of new language design proposed 
for FORTRAN is not, by the criteria in the SD-3, "State of 
the ART". By expecting the augmentations would be taken for 
existing implementations, SD-3 sought to assure that 
FORTRAN’S eficiency and reasonable implementation costs 
would not be changed in unexpected ways. 

Thus major extensions to FORTRAN 8x should be limited to 
areas : 

A. Where there is existing FORTRAN implementation experi¬ 
ence wtth those or similar extensions, so that, prior to 
standardization, it can be determined that efficient proces¬ 
sors are possible at reasonable cost - this may necessitate 
optional features or subsets. The proposals for array 
operations, for example, are in this category. 

B. That relate to portability between implementations. The 
proposals for environmental-intrinsic-functions, for exam¬ 
ple, are in this category. 

The direction of the committee in making significant changes to 
the FORTRAN language is controversial. We believe that the time 
has certainly come for dissemination of information regarding the 
work of X3J3, so that other interested parties may be aware of, 
and have an opportunity to comment on, this direction before a 
proposed standard is submitted for a vote. 

However, we are concerned that an affirmative vote on this bal¬ 
lot, or publication of the document as an information bulletin, 
may be construed by some as a favorable comment on the technical 
direction of X3J3, rather than merely as approving publication of 
the current status. Accordingly, we will change our vote to 
"YES" provided that all comments submitted to X3, including 
these, be published with the document. This will provide readers 
with contrasting views and encourage submission of coaments to 
X3J3. 

We wish to make clear that our support for publication of this 
document does not imply approval of its contents. We believe 
FORTRAN’S combination of "efficiency" and "reasonable implementa¬ 
tion cost", together with the large Investment in existing FOR¬ 


TRAN programs 
most widely 
SD-3, the 3.9 
believe that 
X3J3 to become 
may make their 
ed in FORTRAN 
to communicate 


(and programmers) has resulted in FORTRAN being the 
available high level language and that, as stated 
standard protects these investments. We strongly 
the time has come for interested parties outside of 
aware of the committee’s direction so that they 
own assessments. We encourage all those lnterest- 
to study the issues inherent in this document and 
their views to X3J3. 



RESPONSE TO IBM AND DEC COMMENTS 
Jeanne Adams, Chair, X3J3 
May IS, 1984 

We wish to thank IBM and DEC for their careful study of the 
FORTRAN Information Bulletin Number 1. From your comments, we 
note that you approve of our efforts to solicit comments before 
the draft standard is released from X3J3. X3J3 wishes to incor¬ 
porate the two requests from Digital Equipment in the reponses. 
First, the last sentence of the first paragraph should be 

expanded to "The committee welcomes comments on any and all 
aspects of the features described in this Information Bulletin." 
Second, the last sentence of the second paragraph should be 

expanded to "No FORTRAN 77 features will be removed; it remains 
X3J3*8 intent that any standard-conforming FORTRAN 77 program 
will be a standard-conforming FORTRAN 8x program, and that, with 
any exceptions clearly listed in the document, new FORTRAN 8x 
features can be compatibly incorporated into such programs.” 

The FIB is intended to be a reasonably comprehensive summary of 

current proposed features for FORTRAN 8x, especially of the 

proposed features that are not in FORTRAN 77. A vote approving 
the FIB for publication, either by X3 or X3J3, does not imply 
approval of the technical content. 

During the coming year we plan to have at least four FORTRAN 
Forums throughout the country explaining the facilities that we 
have proposed. 

Two surveys have been conducted, one by ECMA and one by CERN, to 
solicit the opinion of users internationally. A questionnaire 
has been developed for distribution at the Forums and with the 
publication of the bulletin to make the comments more concrete 
than would otherwise occur. Our plan is to publish the FIB in 
both SIGNUM and FORTEC of the ACM with CBEMA's permission and the 
X3 vote of approval to publish. 

X3J3 does not support the publication of any comments with the 
FIB, and would prefer to withdraw the FIB if it cannot be pub¬ 
lished without commentary. It would be much better to generate 
survey results from the user community on the new features and 
present those along with a larger comment base than just the two 
from IBM and DEC. I also feel that publishing comments without 
the X3J3 response to that comment gives X3J3 too little oppor¬ 
tunity to explain the feature and its desirability. 

In closing, we appreciate IBM's comments on the useful and 
enthusiastic work of X3J3. Our goal is to produce the best 
possible standard for users of FORTRAN. The technical work of 



AN EDITORIAL 

If you have been reading other newsletters, you may realize 
by now that the question of combining the SIG newsletters into 
one composite journal has been circulating through the various 
DECUS committees. This is an issue that J, as an editor and 
DECUS member, feel very strongly about, and have participated in 
some of the discussions and proposals relating to it. I would 
like to take the opportunity to present my feelings on the 
matter, and ask that you make your feelings known to the ap¬ 
propriate people. Please note that what follows is strictly my 
personal opinion, and is not necessarily endorsed by DECUS, the 
operating committees, or even the LTSIG steering committee. 

Early this year the SIG publications committee met in Marlboro to 
address this issue. What follows is the text of a message I sent 
to interested parties prior to that meeting, expressing my feel¬ 
ings. 


The current discussion concerning combining the SIG 
newsletters into one large journal has raised a lot of issues, 
both substantial and emotional. To cut through the confusion, it 
would be helpful to enumerate the problems which are faced by the 
newsletters, and whether this mode of attack on those problems 
solves them, alleviates them, or contributes to them. Only then 
can we go on to approve the idea, or propose alternatives. 

As I understand the issue, DECUS members have been charged 
for newsletters, and are not getting a fair return for their mo¬ 
ney from the SIG's which have not been publishing. This has led 
to angry calls to DECUS from those members, and concern among the 
DECUS staff for the Society’s legal responsibility. While the 
general membership may not be aware of the exact numbers, each 
SIG committed to publish a certain number of newsletters per 
year, and the subscription rates were based partly on that infor¬ 
mation. It is important to realize, that while the immediate 
concern is issue count, that is not the real problem. Each 
member has paid for information , and is upset that he or she is 
not getting that information . If we are truly to address the 
root problem, we have to seek ways which will maximize the flow 
of information to the member. 

The current question is whether the various SIG newsletters 
will be combined into a composite journal. The arguments in 
favor of this are that it will reduce the cost of printing 
newsletters, so that subscription prices will go down; sub¬ 
scribers will always get something each month, so they cannot 
complain about unfulfilled subscriptions; and the SIG's can pub¬ 
lish short timely articles, even if they do not have enough for a 
full newsletter. I cannot address the first issue, since I don't 
have the information available to me to make an analysis. Suf¬ 
fice it to say that on one hand the cost will decrease due to a 
single large production run as opposed to several small ones, but 
this will be partially offset by the cost of distributing all the 
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information to every subscriber, rather than printing and ship¬ 
ping just what each subscriber wants. 

If we examine the other arguments in terms of maximizing the 
flow of information, the results are questionable. Even though a 
subscriber may get something each month, it is not necessarily 
what he wants. A large portion of each monthly journal would be 
made up of the VAX SIG, RSX, and other large newsletter’s data. 
To the subscriber who is interested in RSTS, for example, this is 
just wasted paper. What we will have done is turn a number of 
special purpose publications into a large generic one, which may 
or may not have what people want. The only possible answer to 
this is the third argument quoted above, that smaller portions of 
information can be published, which might otherwise not be suffi¬ 
cient for a newsletter unto themselves. This indeed may be true, 
but it implies that newsletter editors frequently find themselves 
with one or two items to publish, sitting around waiting for 
more. Is this necessarily true, or do they frequently find then- 
selves waiting for anything to publish, and when they have it 
generate enough filler to go around it? The real issue is how to 
get more information to the editors, not how to spread out what 
little they have further. Actually, I suspect that if the 
newletters are combined into a single journal, there will be less 
information published, since there will be less pressure on the 
newsletter editors to get something out. A likely attitude for 
the smaller SIG’s which have problems getting material together 
will be to let it slide, hoping for more input, and knowing that 
something will be published, whether they contribute or not. 
Similarly, contributions from users, which are at the heart of 
the newsletters, will probably go down. It is difficult enough 
now to convince someone to contribute an article for a small 
newsletter. They will be all that much more intimidated and un¬ 
likely to submit their hints or questions if they are to be pub¬ 
lished in a several hundred page magazine. Once again, it is a 
question of a perceived value to the contribution. In a small 
newsletter every effort and contribution is important; if the 
newsletters are combined, there will be less incentive for every¬ 
one, both editors and contributors alike. 

What are the disadvantages to the combined journal?' Besides 
the serious argument above that it might actually reduce the con¬ 
tributions from some SIG’s, there are several. Unfortunately 
they are mostly intangible possibilities. First and foremost, 
though, it only covers up the situation, and does not address the 
root problem, which is maximizing the flow of useful information 
to the subscriber. Unless we do something to help (and train) 
newsletter editors, this problem will remain, regardless of the 
physical format of the newsletters or journal. There are also 
the vague, uneasy concerns which have been frequently voiced. 
Will page counts be imposed? will there be some sort of oversee¬ 
ing editor affecting what the SIG’s publish? Will SIG’s be prior¬ 
itized, such that, for example, IAS or APL articles are postponed 
if VAX has a major contribution? It is easy to deny these prob¬ 
lems, but the simple truth is that they will at some time have to 
be faced. If we take the decision now to combine the 
newsletters, avowing that the problems above will not be allowed 
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to occur, it will be all too easy, in a year or so, to start im¬ 
posing limits and what not, and all too difficult to revert to 
separate newsletters. It will be a logistical mess to combine 
the newsletters. If we do combine them, there will be great 
pressure in the future to make the system work, even if it turns 
out to have been a poor decision. Any promises of a SIG’s auton¬ 
omy, or right to publish what it wants when it wants, will be 
meaningless then. 

What are the alternatives to combining the newsletters? Un¬ 
fortunately there is no other bold stroke, which will, in one 
fell swoop, solve all our problems. The problems faced by the 
SIG newsletters are not that simple. The only real alternative 
is to take the current system, of paid, individual newsletters, 
and try in many little ways to make it work better. Recently the 
DECUS office distributed to the newsletter editors the audio 
tapes of the sessions their SIG sponsored in Anaheim. While not 
as dramatic as combining the newsletters, this is a positive step 
towards helping the editors. There are many steps of this sort 
which could be taken: providing training for editors, helping 
them contact possible sources of information within DEC, coordi¬ 
nating with the library service to locate users of specific li¬ 
brary programs, and probably many more. These types of actions 
will make the newsletter content better, and thereby better serve 
the subscriber. Combining the newsletters only serves to cover 
up the real problem. 

In summary, I feel that combining the newsletters into one 
journal, while an honest attempt to address the problems faced by 
DECUS and the SIG’s, is misguided for a number of reasons. 
First, it does not address the true issue, which is getting more, 
and more useful, information to the user community. Secondly, it 
will probably lead to a decrease in the contributions to the 
newsletters. Finally, it will inevitably alter the nature of the 
newsletters for the worse, leading them away from a user based 
interchange of information, and towards a more public, superfi¬ 
cial, magazine. DECUS has attempted to address the issue of 
newsletters several times over the past few years. Subscription 
rates were imposed, every year new combinations of newsletters 
were announced, and so forth. In spite of all this, subscrip¬ 
tions have gone down, and fewer newsletters have been published. 
I talked to several people in Anaheim who did not know if tney 
were supposed to be receiving newsletters, Since they hadn't been 
able to keep track of the changes in the subscription services. 
I believe it is time to stop trying to make changes to the 
current system, and not only give it a chance to work, but help 
it to work. This is a more difficult challenge than proposing 
patches and changes, but is the only one which really serves the 
DECUS community. As any member of ACM or other societies knows, 
late issues and lack of contributions are a chronic problem for 
special interest newsletters. If we help the newsletters over¬ 
come those problems, however, they provide a service and inter¬ 
change of information which can't come from any large periodical. 
A combined journal will lose that special nature, and will do 
nothing but save face in return. 


114 



At the meeting in Marlboro, we discussed several issues re¬ 
lating to combining the newsletters, including printing costs. 
In the course of the discussions, which included conversations 
with the printers, it came out that printing costs would most 
probably rise with a combined newsletter. The committee at that 
point was unanimous in recommending that the newsletters not be 
combined, and instead recommended a variety of steps designed to 
improve the current quality of the single SIG publications. 

Since that time the Communications Committee has spent a 
great amount of time defending that recommendation. Recently, 
the DECUS Management Council has put forth a new proposal for a 
combined newsletter which, in my own opinion, ignores both the 
recommendations and concerns of the Communications Committee. 
For example, it explicitly puts page limitations on the various 
SIGs, and spells out what type of material will and will not be 
allowed to be published. The various handouts which I reprinted 
in the last issue would most probably not be allowed under the 
proposed rules. The Management Council has also offered to sub¬ 
sidize the combined newsletter format, but has not made a similar 
offer regarding the individual newsletters. Unless there is 
widespread opinion expressed to the contrary, the Management 
Council will most likely overrule the Communications Committee, 
and mandate this new format. 

How do you feel about this issue? If you support my 
viewpoint, it is imperative that we make our feelings known en 
masse to the Management Council. Please take the time to write 
to them and express your feelings. Their names are listed in 
every issue of DECUScope. You may also send your comments to me, 
and I will try to distribute them to the appropriate people. 
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